Re: [w3c/IndexedDB] How should IDB connections and outstanding IDB transactions behave when a page enters back/forward cache? (Issue #381)

> The reason I gave that example was because I thought a readonly txn would not block a readwrite txn. [This comment](https://github.com/w3c/IndexedDB/issues/253#issue-400861260) says that Chrome implemented snapshots and that readonly txns do not block new readwrite txns. I don't know if that rolled out but it seems like a reasonable thing to do and I see no reason to prevent it in the spec.

If you read that comment thread in more detail, it says that Chrome _had_ implemented snapshots, but that this was proving to be a compatibility issue for developers so the implementation was changed and the spec made more restrictive. It's best to think of readonly transactions as holding shared locks over their scope, and readwrite transactions as holding exclusive locks over their scope.

> Can we just say that the page1 must be marked unsalvageable if
> 
> * page2 opens the DB with a higher version

Or attempts to delete the database.

> * page2 starts any kind of write txn that overlaps with any of page1's write txns

As noted above, there are more permutations. See https://w3c.github.io/IndexedDB/#transaction-scheduling

We might be able to get away with inserting something akin to "if a transaction could be started if transactions in non-fully-active contexts were aborted, then those transactions must be aborted and the contexts marked unsalvageable" or something. 

(Note that IDB is usable from workers, so we can't just say "page", I'm not sure of the spec text for dealing with a page's tree of dedicated workers.)

Note the case where page A has a lock on [s1], page B is waiting for a lock on [s1, s2] and page C is waiting for a lock on [s2]. If page B were destroyed, page C's transaction should be able to start. But if A had a lock on [s1, s2] instead, destroying page B wouldn't unblock C. Presumably that makes whether page B can enter the BFCache observable, so we need to spec carefully here.


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

Message ID: <w3c/IndexedDB/issues/381/1133117518@github.com>