- From: Aaron Boodman <aa@google.com>
- Date: Tue, 8 Sep 2009 01:54:37 -0700
On Tue, Sep 8, 2009 at 1:41 AM, Robert O'Callahan<robert at ocallahan.org> wrote: > What is the intended semantics here? Chris' explicit commitTransaction would > throw an exception if the transaction was aborted due to data inconsistency, > leaving it up to the script to retry --- and making it clear to script > authors that non-storage side effects during the transaction are not undone. > How would you handle transaction aborts? Calls to transaction() are queued and executed serially per-origin with exclusive access. There is no such thing as a transaction abort because there cannot be consistency problems because of the serialized access. > You'd have to implement it via a mutex. I think you would have a queue of all pending requests for access to storage, along with their associated callbacks, message loops, and execution environments. Each time the local storage frees up, if there is any queued request, invoke the callback in the correct environment. > An optimized implementation could > wait until the first operation that can't be un-done before acquiring it, > and do everything optimistically until then. This is the same situation as > WebDatabase if I understand it correctly. You can't do this because upgrading the lock could block the UI thread. Same thing with the database spec. If you want to get fancy, the transaction() method can take a read/write param. This is what the database spec does, but I think it is overkill here, personally. - a
Received on Tuesday, 8 September 2009 01:54:37 UTC