IndexedDb transaction auto-commit behavior in edge cases

Question

Tx is committed when :

• request success callback returns - that means that multiple requests can be executed within transaction boundaries only when next request is executed from success callback of the previous one
• when your task returns to event loop

It means that if no requests are submitted to it, it is not committed until it returns to event loop. These facts pose 2 problematic states :

• placing a new IDB request by enqueuing a new task to event loop queue from within the success callback of previous request instead of submitting new request synchronously
  • in that case the first success callback immediately returns but another IDB request has been scheduled
    • are all the asynchronous requests executed within the single initial transaction? This is quite essential in case you want to implement result pulling with back-pressure where consumer gives you a feedback in form of a Future that it is ready to consume another response
• creating a ReadWrite tx, not placing any requests against it and creating another one before returning to event loop
  • does creating a new one implicitly commits the previous tx ? If not, serious write lock starvations might occur, because :

If multiple "readwrite" transactions are attempting to access the same object store (i.e. if they have overlapping scope), the transaction that was created first must be the transaction which gets access to the object store first. Due to the requirements in the previous paragraph, this also means that it is the only transaction which has access to the object store until the transaction is finished.

The example of enqueuing a new task to event loop queue from within the success callback by recursive request submission with back-pressure :

    function recursiveFn(key) {
      val req = store.get(key)
      req.onsuccess = function() {
        observer.onNext(req.result).onsuccess { recursiveFn(nextKey) } 
      }
    }

Observer#onNext // returns Future[Ack] Ack is either Continue or Cancel

Now can onsuccess or onNext do a setTimeout(0) or not to make the whole thing be part of one transaction?

Bonus question :

I think that ReadOnly transactions are exposed to the consumer/user just because it would be hard to detect the end of a batch read if you recursively submit new requests from the success callback of the previous one right? Otherwise I don't see any other reason for them to be exposed to a user, right ?

Answer 1

I'm not sure I understand your question completely but I'll offer an answer on whether you can safely use IDB transaction events to move a state machine.

Yes and no. Yes in theory, no in practice.

I think you understand the transaction lifetime. But to rehash:

The lifetime of a transactions lasts as long as it's referenced: it's "active" so long as it's being referenced, after which it is said to be "finished" and the transaction is committed.

In theory, oncomplete should fire whenever a transaction successfully commits. There's a useful tip in the spec on this that suggests how you could loop:

To determine if a transaction has completed successfully, listen to the transaction’s complete event rather than the IDBObjectStore.add request’s success event, because the transaction may still fail after the success event fires.

To safely use this mechanism be sure to watch for non-success events including onblocked and onabort as well.

Practically speaking, I've found transactions to be flakey when long-lived or done consecutively in batches (as you've noted in another IDB comment). I'm generally not engineering my apps to require tricky behavior because, no matter how the spec says it should behavior, I'm seeing wonky transactions in both Firefox and Chromium (but mostly Blink, interestingly) especially when multiple tabs are open.

I spent many weeks rewriting dash to reuse transactions for supposed performance gains. In the end it could not pass even my basic write tests and I was forced to abandon simultaneous/queued/consecutive transactions and rewrite once again. This time I picked a one-transaction-at-a-time model which is slower but, for me, more reliable (and suggest to avoid my lib and use something like ydn for bulk inserts).

I'm not sure on your application requirements, but in my humble opinion tying in your I/O into your event loop seems like a disastrous idea. If I needed an event loop as what I understand to be the term I would definitely use requestAnimationFrame() and throttle that callback if I needed fewer ticks than one per ~33 milliseconds.