On Sat, Jul 25, 2009 at 11:22 AM, Laxmi Narsimha Rao Oruganti<[email protected]> 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
