This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Tracking bug for this conversation: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0575.html Short version, c/o Jonas: "Specifically, there is nothing that says that if a readonly transaction is created after a readwrite transaction, that the readonly transaction runs after the readwrite transaction. This is true even if the two transactions have overlapping scopes." .. and then further details about this, since Chrome takes advantage of this but it can be unexpected for developers.
I suggest replacing the paragraph starting with "If multiple "readwrite" transactions are attempting..." with the following: Any transaction _created_ after a "readwrite" transaction MUST see the changes written by the "readwrite" transaction. So if a "readwrite" transaction, A, is created, and later another transaction B, is created, and the two transactions have overlapping scopes, then B MUST see any changes made to any object stores that are part of that overlapping scope. Due to the requirements in the previous paragraph, this also means that the B transaction does not have access to any object stores in that overlapping scope until the A transaction is _finished_. And then change the note to: Generally speaking, the above requirements mean that any transaction which has an overlapping scope with a "readwrite" transaction and which was created after that "readwrite" transaction, can't run in parallel with that "readwrite" transaction.
Just confirming: are we file with still allowing "readonly" transactions to snapshot and thus not block subsequently created "readwrite" transactions with overlapping scope? Spec text is: "There are a number of ways that an implementation ensures this. The implementation can prevent any "readwrite" transaction, whose scope overlaps the scope of the "readonly" transaction, from starting until the "readonly" transaction finishes. Or the implementation can allow the "readonly" transaction to see a snapshot of the contents of the object stores which is taken when the "readonly" transaction started." Chrome implements snapshots, Firefox does not appear to, i.e. in FF a readonly transaction will block a readwrite transaction with overlapping scope. I was thinking of this as the same issue, but I'm okay with a more scoped change as well.
I've incorporated Jonas' suggestions in comment #1 the ED
(In reply to Joshua Bell from comment #2) > Just confirming: are we file with still allowing "readonly" transactions to > snapshot and thus not block subsequently created "readwrite" transactions > with overlapping scope? Yup. The proposal that I put in comment 1 still allows that, right? > Chrome implements snapshots, Firefox does not appear to, i.e. in FF a > readonly transaction will block a readwrite transaction with overlapping > scope. I was thinking of this as the same issue, but I'm okay with a more > scoped change as well. I'm fine that. This doesn't seem to result in interoperability problems. Just results in Firefox being slower. Do you agree?
(In reply to Jonas Sicking from comment #4) > Yup. The proposal that I put in comment 1 still allows that, right? Yes. > I'm fine that. This doesn't seem to result in interoperability problems. > Just results in Firefox being slower. > > Do you agree? Agreed.