Re: [IndexedDB] onsuccess isn’t the best for writes

Unrelated:

"If an exception was propagated out from any event handler while
dispatching the event in step 3, abort the transaction by following the
steps for aborting a transaction using transaction as transaction
parameter, and AbortError as error."

Exceptions don't propagate out of event handlers.  APis shouldn't do things
with events that can't be done in JavaScript using dispatchEvent.  If we
really want to vary behavior depending on whether an exception was thrown
from an event handler, that should be specified by DOM4 and exposed to JS.

It also seems inconsistent: the transaction is aborted if code fails inside
onsuccess, but not if it fails almost anywhere else, which seems much more
likely anyway.  I don't think anything else on the platform has special
error handling like this; I'd recommend just removing it.


On Mon, Mar 19, 2012 at 7:38 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > (What does "when a transaction can no longer become active" mean?  It
> > doesn't seem to be defined.)
>
> All places when transactions can become active are defined, so it be
> unambiguous.


APIs should be specified explicitly, not by inference.

We also have some non-normative text which makes it
> easier for authors reading the spec.
>
> If you have proposals for clearer wording though I'd be all for that.
>

It sounds like you want to commit transactions if you're in the event loop
and a request has no outstanding requests (eg. they've all received their
onsuccess or onerror events).

As a starting point, add to "Steps for asynchronously executing a request":

"8. If the transaction's active flag is false, its request list is empty,
and it has not been aborted, queue a task to *commit* transaction.**"

Modify "Transaction Creation steps" step 5 to say:

When control is returned to the event loop, perform the following steps:
1. Set the active flag to false.
2. If the transaction's request list is empty and the transaction has not
been aborted, *commit* transaction.

That's just a rough start, of course, but it's a much clearer and more
explicit way of defining when transactions are committed.

-- 
Glenn Maynard