The text in transaction lifetime about "when a transaction can be started" doesn't define an algorithm (unlike e.g. web locks). Instead, it just defines preconditions. Specifically for this case:
- ... As long as a read-only transaction is running, the data that the implementation returns through requests created with that transaction must remain constant ...
Which is then followed by the note:
There are a number of ways that an implementation can ensure this. The implementation could prevent any read/write transaction, whose scope overlaps the scope of the read-only transaction, from starting until the read-only transaction finishes. Or the implementation could allow the read-only transaction to see a snapshot of the contents of the object stores which is taken when the read-only transaction started.
Chrome implemented snapshots, and therefore allowed a readwrite transaction to start even while a readonly transaction overlapping scope was still running. e.g.
const tx1 = db.transaction('store', 'readonly');
const tx2 = db.transaction('store', 'readwrite');
Both tx1 and tx2 could start immediately; operations within tx1 would see a snapshot of the data.
Other engines (Firefox, Safari, Edge) did not implement this; tx2 would not start until tx1 finished.
Chrome is changing this as part of a rework of the implementation; we actually had a non-WPT test asserting this behavior, which broke.
Following this change, all engines will behave the same way - the readonly transactions must finish before the readwrite transaction can start. Should we codify that in the spec and WPTs?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3