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