[Webkit-unassigned] [Bug 29218] New: Write transactions should start with a BEGIN IMMEDIATE command

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29218

           Summary: Write transactions should start with a BEGIN IMMEDIATE
                    command
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dumi at chromium.org
                CC: beidson at apple.com, dglazkov at chromium.org,
                    michaeln at google.com, aroben at apple.com,
                    andersca at apple.com


Thanks to Michael for pointing this out!

http://www.sqlite.org/lockingv3.html:
SHARED lock: The database may be read but not written. Any number of processes
can hold SHARED locks at the same time, hence there can be many simultaneous
readers. But no other thread or process is allowed to write to the database
file while one or more SHARED locks are active.
RESERVED lock: A RESERVED lock means that the process is planning on writing to
the database file at some point in the future but that it is currently just
reading from the file. Only a single RESERVED lock may be active at one time,
though multiple SHARED locks can coexist with a single RESERVED lock.

Currently, when we start a transaction, we issue a BEGIN command. According to
http://www.sqlite.org/lang_transaction.html, BEGIN does not acquire any lock on
the DB file. Then the first read operation acquires a SHARED lock, and the
first write transaction escalates the lock to RESERVED. This can lead to
failing write transactions. For example:

transaction_1:
SELECT ...
UPDATE ...

transaction_2:
INSERT ...

transaction_1 is allowed to execute the first statement. Since it's a SELECT
operation, transaction_1 acquires only a SHARED lock. Now transaction_2 runs;
it acquires a RESERVED lock and changes the database. Now transaction_1 resumes
and tries to update the database too, but since the database was changed by
transaction_2, the UPDATE operation fails.

We think the correct way to do this is to start all write transactions with a
BEGIN IMMEDIATE command, which acquires a RESERVED lock before executing any
statement. This would make transaction_2 wait for transaction_1 to finish, and
both transactions would complete successfully.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.