"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."
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@...> 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
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.