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

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