HTML and CSS Reference
In-Depth Information
This code is actually doing quite a lot on the last three lines,
and if you're like me, you might think there's some unnecessary
repetition.
We're performing three separate tasks, outlined below.
1. Create the transaction
transaction = db.transaction(['blockbusters'], READ_WRITE)
The first task is to create a new transaction with read and write
permission to the named object stores. A transaction can be
bound to more than one object store, which is why we're pass-
ing in an array here. In practice I've found that I could pass null
or even an empty string in the object store name argument. I'm
not sure that's valid, or if it should really work, but like I said:
IndexedDB is new and still in vendor-prefix mode, so it's best to
stick to what the spec suggests.
Also, if we were just planning to execute read operations in the
transaction, we could use IDBTransaction.READ_ONLY .
A day in the short life of a transaction
Transaction objects have a very short lifetime linked to the event loop
in a browser. If you create a transaction and don't use it and return to
the event loop, the transaction will be dead and unusable.
If, however, you run the request immediately, and if the request is suc-
cessful, you can choose to place a subsequent request on the trans-
action and be safe in the knowledge that it will still be alive. You can
continue to do this so long as you don't break for the event loop.
If you've ever used a setTimeout(fn, 0) in your code, you've
released to the event loop—maybe to allow the browser to repaint the
page, maybe for something else.
This is a fairly unique concept that I've not seen before, so definitely
experiment with the transaction lifetime. Once you've got a good
handle on when it's alive and when it's dead, you'll be able to make
the transaction last longer than a zombie.
 
Search WWH ::




Custom Search