Re: [w3c/IndexedDB] Add IDBTransaction commit() method (#242)

I think there's a hole or two in the spec around the "committing" state and aborting, at least as I understood the intent of the commit() changes to be.

Previously, the spec abstracted away most of the realities of the IDB logic running on some other event loop that's asynchronously accessed.  A transaction being "finished" was accordingly posed as whether "commit a transaction" or "abort a transaction" had run.  "Commit a transaction" now surfaces this reality by introducing the "committing" state so that new requests can't be issued and to more accurately express that the already-enqueued requests could still fail and cause the transaction to abort.

The issues I see with the patch as stands are:
- abort() post-patch only checks for a state of transaction/finished before throwing.  This creates an awkward semantic state where `commit(); abort();` could be invoked and neither method would throw because abort() is okay with being invoked with the transaction in the "committing" state, but either one of the two results could happen depending on the implementation.
- Similarly, it seems like "fire a success event" can still trigger an (ambiguous) abort even after commit() is called.  It directly invokes the "abort a transaction" algorithm without any guards, but I think a transaction state check of [committing, finished] is appropriate.  ("Fire an error event" does this too, but we would expect the abort to have been internally triggered in that case already?).
- commit() should probably mention the impact it will have on "success" events if we are going with what I understood.  So we'd explicitly say that they will still fire but if they throw, the transaction will not be aborted.  Also we'd possibly say that the transaction will still commit even if the events are unable to be fired.  For example `transaction.commit(); self.close();` in a worker should still cause the transaction to commit.
- transaction/lifetime should also mention the "committing".  Alternately, the "finished" state could perhaps instead be "completed" and the original semantics of "finished" meaning "abort a transaction" or "commit a transaction" having been invoked (at least once) could be restored.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/pull/242#issuecomment-400734238