- From: Aaron Boodman <aa@google.com>
- Date: Sat, 25 Jul 2009 12:46:22 -0700
- To: Laxmi Narsimha Rao Oruganti <Laxmi.Oruganti@microsoft.com>
- Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Ian Hickson <ian@hixie.ch>, public-webapps WG <public-webapps@w3.org>
On Sat, Jul 25, 2009 at 11:22 AM, Laxmi Narsimha Rao Oruganti<Laxmi.Oruganti@microsoft.com> wrote: > There seems to be Update Loss issue here. If the UI thread which is supposed to enqueue the statements was scheduled out in the middle of a transaction block. And the background thread got scheduled in, consumed the already queued items alone part of transaction and committed. That means, we have lost atomicity right. I am sure spec did not intend this. There is no update loss issue. Assuming the implementation used threads (it could use a separate process, too), after each statement is run on the background thread, if it has any callbacks, those callbacks are run on the UI thread [4.3.2 Step 6.5]. The transaction is not committed until all queued statements and their associated callbacks have run. Since it is only valid to queue statements within SQLTransactionCallback, SQLStatementCallback, or SQLStatementErrorCallback [4.3.1 Step 1], and the background thread waits for those callbacks to complete, there is no race. - a
Received on Saturday, 25 July 2009 19:47:01 UTC