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.

> 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.

> 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.)

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.







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

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

Received on Thursday, 19 May 2022 16:15:43 UTC