- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 13 Jul 2011 01:18:38 -0700
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, David Sheldon <dsheldon@microsoft.com>
On Tue, Jul 12, 2011 at 7:23 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> A couple of questions regarding client state vs. server state on several calls. What should be the client behavior for subsequent calls after a transaction abort is called? This assumes the server request hasn't been processed yet. For example:
>
> 1. var txn = db.transaction([osName], IDBTransaction.READ_WRITE);
> 2. objStore = txn.objectStore(osName);
> 3. var rq = objStore.add(books[2]).onsuccess = function (e1) { log("added book 2"); };
> 4. txn.abort();
> 5. try {
> 6. var rq2 = objStore.add(books[3]).onerror = function (e2) { log("failed to add book 3"); };
> 7. catch (ex) {
> 8. log ("TRANSACTION_INACTIVE_ERR");
> 9. }
>
> I expect that line #3 will receive the success event.
No, after .abort() is called, only error events will fire on any
request still pending on the transaction. This includes read and write
events alike. This is defined in step 3 of "steps for aborting a
transaction" (formerly step 2, see below).
Trying to get some events to succeed is likely a waste of CPU cycles
as the reads might not have happened yet at the time when .abort() is
called. In fact, that is likely the case in your example above. So
we'd have to sit tight waiting for such events to succeed before being
able to roll back the transaction. In most cases this would seem like
a waste of resources. The user called .abort() for a reason after all.
By making *all* unfinished requests fire a error events, even once
that potentially has read data but not yet fired a success event, we
make things consistent and non-racy.
> However, I expect that rq2 will throw a TRANSACTION_INACTIVE_ERR that will be processed by line #7 and that the onerror function will never be called on line #6. My assumption is that even if the transaction abort hasn't been processed by the server, that the client state associated with the transaction will contain an invalid transaction and thus fail.
>
> Do you agree?
Yes. Though this doesn't actually appear to be defined. I fixed this
by adding a new step 1 of "steps for aborting a transaction" which
says:
1. Set transaction's active flag to false.
Hope this looks good?
/ Jonas
Received on Wednesday, 13 July 2011 08:19:35 UTC