Question

Instead of opening several transactions (read a table, write to a table, write to another table, etc) is it possible to do this all from a single transaction as long as you are using an appropriate IDBTransaction?

Mozilla says: “The only way to keep the transaction active is to make a request on it. When the request is finished you’ll get a DOM event and, assuming that the request succeeded, you’ll have another opportunity to extend the transaction during that callback.” which is a little vague. Does that mean if I provide an event handler for the DOM callback that I can use the transaction at any point in that callback without ever having to worry about the transaction being closed?

https://developer.mozilla.org/en/IndexedDB/Using_IndexedDB#Adding_data_to_the_database

Answer 1

IndexedDB transactions commit as soon as the last callback is fired, so the way to keep them alive is to pass them along via callbacks.

I’m sourcing my transaction info from Jonas Sicking, a Mozilla dev and co-spec writer for IndexedDB, who commented on this excellent blog post to say the following:

The following sentence isn’t correct “Transactions today auto-commit
when the transaction variable goes out of scope and no more requests
can be placed against it”.

Transaction never automatically commit when a variable goes out of
scope. Generally they only commit when the last success/error callback
fires and that callback schedules no more requests. So it’s not
related to the scope of any variables.

The only exception to this is if you create a transaction but place no
requests against it. In that case the transaction is “committed”
(whatever that means for a transaction which has no requests) as soon
as you return to the event loop. In this scenario you could
technically “commit” the transaction as soon as all references to it
go out of scope, but it’s not a particularly interesting use case to
optimize.