[w3c/IndexedDB] Disallow starting readwrite transactions while readonly transactions are running? (#253)

The text in [transaction lifetime](https://w3c.github.io/IndexedDB/#transaction-lifetime-concept) about "when a transaction can be started" doesn't define an algorithm (unlike e.g. [web locks](https://wicg.github.io/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.

```js
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?


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