W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [indexeddb] Implicit Transaction Request associated with failed transactions

From: David Grogan <dgrogan@chromium.org>
Date: Wed, 5 Oct 2011 13:25:43 -0700
Message-ID: <CAOZbSt1znjA156Q1+G7T2gv9JuQX6NWM2nc0rYm5v6jmnZ0MJg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Israel Hilerio <israelh@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Jim Wordelman <jaword@microsoft.com>, Tom Bolds <thombo@microsoft.com>, Cullen Sauls <cullens@microsoft.com>
On Tue, Oct 4, 2011 at 3:01 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> >> Based on previous conversations, it seems we've agreed that there are
> situations in which a transaction could failed independent of explicit
> requests (i.e. QUOTA_ERR, TIMEOUT_ERR).  We believe that this can be
> represented as an implicit request that is being triggered by a transaction.
>  We would like to add this concept to the spec.  The benefit of doing this
> is that it will allow developers to detect the error code associated with a
> direct transaction failure.  This is how we see the concept being used:
> >>
> >> trans.onerror = function (e) {
> >> //eventTarget is mapped to an implicit transaction that was created
> behind the scenes to track the transaction
> >>
> >>  if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >>    // you know the transaction error because of a timeout problem
> >>  }
> >>  else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >>   // you know the transaction error because of a quota problem
> >>  }
> >> }
> >>
> >> Our assumption is that the error came not from an explicit request but
> from the transaction itself.  The way it is today, the e.eventTarget will
> not exists (will be undefined) because the error was not generated from an
> explicit request.  Today, eventTargets are only populated from explicit
> requests.
> >
> > Good catch!
> >
> > We had a long thread about this a while back with the subject
> > "[IndexedDB] Reason for aborting transactions". But it seems to have
> > fizzled with no real conclusion as to changing the spec. In part that
> > seems to have been my fault pushing back at exposing the reason for a
> > aborted transaction.
> >
> > I think I was wrong :-)
> >
> > I think I would prefer adding a .errorCode on IDBTransaction through
> > (or .errorName or .error or whatever we'll end up changing it to).
> > This seems more clear than creating a implicit request object. It'll
> > also make it easy to find the error if you're outside the error
> > handler. With the implicit request, you have no way of getting to the
> > request, and thus the error code, from code outside the error handler,
> > such from code that looks at the transaction after it has run.
> >
> > And the code above would work exactly as is!
> >
> > Let me know what you think?
>
> In detail, here is what I suggest:
>
> 1. Add a .errorCode (or .errorName/.error) property on
> IDBTransaction/IDBTransactionSync.
> 2. The property default to 0 (or empty string/null)
> 3. In the "Steps for aborting a transaction" add a new step between
> the current steps 1 and 2 which says something like "set the errorCode
> property of <var>transaction</var> to <var>code</var>".
>
> This way the reason for the abort is available (through the
> transaction) while firing he "error" event on all still pending
> requests in step 2. The reason is also available while firing the
> "abort" event on the transaction itself.
>
>
LGTM.

We had discussed how to notify the script that a transaction aborted due to
quota during the commit, after all the operations' success handlers had been
called; an errorCode on IDBTransaction is what we were leaning toward.

/ Jonas
>
>
Received on Wednesday, 5 October 2011 20:26:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT