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

> > how page2 could discover that page1 has an open readonly txn?
> 
> If page1 is keeping a readonly transaction alive, and page2 initiates a readwrite transaction with an intersecting set of stores, that transaction will not be able to grab the lock and requests will not be processed until page1's transaction's completes or aborts.

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.

> 
> > Why does a page need to respond to events to keep a txn alive? Again with a readonly txn, why would the txn be aborted just because a queued JS event was not processed?
> 
> IDB's model is based on assuming that events are being processed. A context opens a transaction and issues a request. The transaction is kept alive while there are outstanding requests, so the transaction is alive. The request is completed and an event fires. If the context responds to the event with another request, the transaction stays alive. If the context does not respond to the event with another request, the transaction will attempt to commit.
> 
> If event processing were to be paused, then per IDB semantics the transaction would be kept alive and keep holding locks.

In general for BFCache, it's fine for a page to go into BFCache and come back out and hold a lock that entire time as long as nothing else thought about the lock.

> 
> > Or if a readwrite txn was open but no other page was attempting to access the DB, why do we need to do anything interesting?
> 
> That's potentially valid. Defining/implementing that behavior would be extremely subtle, though.
> 
> (While the bulk of the IDB spec has been rewritten in algorithmic style, the [transaction lifecycle](https://w3c.github.io/IndexedDB/#transaction-lifecycle) section is still mostly assertions about behavior and the processing model ends up being implied/emergent. A preliminary step is probably to rewrite it and get consensus that the new formulation describes all existing implementations.)

Can we just say that the page1 must be marked unsalvageable if
- page2 opens the DB with a higher version
- page2 starts any kind of write txn that overlaps with any of page1's write txns

This is what is required for correctness. Maybe I've missed some other ways that page2 can observe page1's existence.

> Even without anything else trying to access the stores, the page would still be holding backend resources indefinitely until the page is discarded. Again, this seems contrary to the principles mentioned above.

This would seem to be up to implementers. They need to worry about resource usage. BFCached pages unavoidably hold resources (mostly memory but probably some file-handles, maybe some CPU). Implementers can be far more aggressive.

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

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