- From: Joshua Bell <notifications@github.com>
- Date: Wed, 27 Jun 2018 12:51:24 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/pull/242/c400807753@github.com>
Thank you *very* much @asutherland for your detailed feedback. This is extremely helpful, and I'm very happy to have someone else thinking this through. More please! > 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. True. For reference, in the Chrome implementation it would be racy - the transaction would commit if there was no pending work to be done so it actually committed before the abort showed up. Work might be pending due to implementation details, e.g. multi-stage commit (e.g. blob copies) or if the transaction hadn't processed requests yet (e.g. the transaction hadn't even started, etc). I'd be okay with making `abort()` throw if the state was_ committing_. Thoughts? > 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. Agreed, I just missed that. Refined in 9ba00b5ffa5024110bec10ab7c48653e9abb888d > commit() should probably mention the impact it will have on "success" events Great point. Added in ef28100ef28684ab14b72ba9b971ae1f683382fb - note that this appears in the "domintro" (non-normative) block, but suggestions for a better location are welcome. (I may have moved too much text out of the normative method descriptions.) > transaction/lifetime should also mention the "committing". Thanks! Done in ca0f393713b8ad0a0b96a5db34e247622cf3350a > 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. I was thinking about that too. But since `"complete"` is used as the event for "successfully committed" (vs. `'"abort"` for "aborted") I didn't want to overload that already confusing term. Alternate ideas? -- 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-400807753
Received on Wednesday, 27 June 2018 19:51:47 UTC