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

Re: [IndexedDB] Transaction Auto-Commit

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 25 Jul 2011 11:38:10 -0700
Message-ID: <CA+c2ei9MujiP7UFYE+zCG5QfSH6CF07z=5=uLgetAtBtOmjvdA@mail.gmail.com>
To: Joran Greef <joran@ronomon.com>
Cc: public-webapps@w3.org
On Mon, Jul 25, 2011 at 6:28 AM, Joran Greef <joran@ronomon.com> wrote:
> Regarding transactions in the IndexedDB specification (3.1.7 Transaction):
>
>>> "Once a transaction no longer can become active, and if the transaction hasn't been aborted, the implementation must automatically attempt to commit it. This usually happens after all requests placed against the transaction has been executed and their returned results handled, but no new requests has been placed against the transaction."
>
> What does "no longer can become active" mean?

Well.. generally it's exactly the text you are quoting. "after all
requests placed against the transaction has been executed and their
returned results handled, but no new requests has been placed against
the transaction".

If you want the full exact definition, look for all the places that
references the "active" flag for transactions.

>>> "Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended and can lead to bad user experience in some implementations."
>
> How exactly can an author still cause a transaction to span several asynchronous events?

All transactions span all the asynchronously firing events that are
fired against the requests placed against the transaction. So as long
as you're scheduling requests against the transaction it'll keep
running. So if you schedule a million requests against a transaction,
it'll take a while for it to finish. That's all the above quote says.

> For example, start a transaction, read a value, use that value to do something asynchronous outside of IDB (perhaps for a millisecond or two or up to a second), and then write the result of that back to the transaction?

That you can't do. You should do this as two separate transactions.
This is intentional since we want transactions to be short lived.

> If it is indeed possible for an author to prolong a transaction, does that mean the UA is implementing a delay to give transactions with asynchronous dependencies the chance to add requests?

It's not possible. Not other than scheduling requests against a transaction.

> Surely an explicit commit in this case would be preferable for performance reasons (with a UA timeout protecting against developer forgetfulness)? Then again, if a developer forgot an explicit commit, it would only block writes for his particular application.

Note that reads are also blocked if the long-running transaction is a
READ_WRITE transaction.

/ Jonas
Received on Monday, 25 July 2011 18:39:15 GMT

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