- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 7 Mar 2014 17:24:25 -0800
- To: Webapps WG <public-webapps@w3.org>
Hi all, Currently the IndexedDB spec has strict requirements around the ordering for readwrite transactions. The spec says: "If multiple "readwrite" transactions are attempting to access the same object store (i.e. if they have overlapping scope), the transaction that was created first MUST be the transaction which gets access to the object store first" However there is very little language about the order in which readonly transactions should run. Specifically, there is nothing that says that if a readonly transaction is created after a readwrite transaction, that the readonly transaction runs after the readwrite transaction. This is true even if the two transactions have overlapping scopes. Chrome apparently takes advantage of this and actually sometimes runs readonly transactions before a readwrite transaction, even if the readonly transaction was created after the readwrite transaction. This means that a readonly transaction that's started after a readwrite transaction may or may not see the data that was written by the readwrite transaction. This does seem like a nice optimization. Especially for implementations that use MVCC since it means that it can run the readonly and the readwrite transaction in parallel. However I think the result is a bit confusing. I'm not so much worried that the fact that people will get callbacks in a different order matters. Even though in theory those callbacks could have sideeffects that will now happen in a different order. The more concerning thing is that the page will see different data in the database. One example of confusion is in this github thread: https://github.com/js-platform/filer/issues/128#issuecomment-36633317 This is a library which implements a filesystem API on top of IDB. Due to this optimization, writing a file and then checking if it exists may or may not succeed depending on if the transactions got reordered or not. I'd like to strengthen the default ordering requirements and say that two transactions must run in the order they were created if they have overlapping scopes and either of them is a readwrite transaction. But I'd be totally open to adding some syntax to opt in to more flexible transaction ordering. Possibly by introducing a new transaction type. Btw, when are we starting officially working on IDB v2? :) / Jonas
Received on Saturday, 8 March 2014 01:25:22 UTC