W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [indexeddb] Client API state after calling trasnaction.abort

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 13 Jul 2011 01:23:55 -0700
Message-ID: <CA+c2ei_Z5phoQQOoijjUF9BmtF8t3h63Gx6egq7eRiLg-POmjQ@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, David Sheldon <dsheldon@microsoft.com>
On Wed, Jul 13, 2011 at 1:18 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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?

Hmm.. I realized that this isn't the right way to fix this since a
transaction can get aborted asynchronously if for example an
objectStore creation fails. So instead I kept the "steps for aborting
a transaction" as they were and added text to the abort() function
saying that it sets the transaction's active flag to false.

/ Jonas
Received on Wednesday, 13 July 2011 08:24:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC