Re: [IndexedDB] Transaction ordering for readonly transactions
On Mar 10, 2014 10:35 AM, "Joshua Bell" wrote: >> 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. > > > Another benefit is that a connection that's issuing a series of readonly > transactions won't suddenly pause just because a different connection in > another page is starting a readwrite transaction. Good point. >> 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. >> > > And we (Chrome) have also had developer feedback that allowing readonly > transactions to "slip ahead' of busy/blocked readwrite transactions is > surprising. > > That said, developers (1) have been quick to understand that implicit > transaction ordering should be made explicit by not creating dependent > transactions until the previous one has actually completed - and probably > fixing some application logic bugs at the same time, and (2) have taken > advantage of readonly transactions not blocking on readwrite transactions, > achieving much higher throughput without implementing their own data caching > layer. > > So I'm definitely of two minds here. Removing this optimization will help > developers in simple cases, but would hinder larger scale web apps. Other > opinions? I agree that supporting the high-peeformance use case is important. But it seems surprising that you can depend on transaction scedulibg for readwrite transactions but not for readonly. I.e. it seems strange that you can work around this optimization by switching your readonly transactions to readwrite (as was done in this case). >> 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. > > > Making the complexity opt-in sounds like a reasonable compromise. Cool, something like "reordarable" might work. "reorderable-readonly" is more descriptive but is terribly long. Another issue is feature detection. Maybe we should introduce functions like readonlyTransaction() readwriteTransaction() reorderableTransaction() (That would have also gotten us out of the extended argument we had about what the default transaction type should be) >> Btw, when are we starting officially working on IDB v2? :) > > > ASAP! We've got some things implemented behind experimental flags in Chrome > (binary keys, continuing-on-primary-key, etc) and want to push forward with > more details on events, storage types (persistent vs. temporary) etc. Perhaps > a topic for the F2F next month (offline or during the meeting?) would be > "current best practices for 'v2' specs"? Sounds good! / Jonas
Re: [IndexedDB] Transaction ordering for readonly transactions
On Fri, Mar 7, 2014 at 5:24 PM, Jonas Sicking wrote: > 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. > That is correct. > > 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. > Another benefit is that a connection that's issuing a series of readonly transactions won't suddenly pause just because a different connection in another page is starting a readwrite transaction. > > 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. > > And we (Chrome) have also had developer feedback that allowing readonly transactions to "slip ahead' of busy/blocked readwrite transactions is surprising. That said, developers (1) have been quick to understand that implicit transaction ordering should be made explicit by not creating dependent transactions until the previous one has actually completed - and probably fixing some application logic bugs at the same time, and (2) have taken advantage of readonly transactions not blocking on readwrite transactions, achieving much higher throughput without implementing their own data caching layer. So I'm definitely of two minds here. Removing this optimization will help developers in simple cases, but would hinder larger scale web apps. Other opinions? > 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. > Making the complexity opt-in sounds like a reasonable compromise. > > Btw, when are we starting officially working on IDB v2? :) > ASAP! We've got some things implemented behind experimental flags in Chrome (binary keys, continuing-on-primary-key, etc) and want to push forward with more details on events, storage types (persistent vs. temporary) etc. Perhaps a topic for the F2F next month (offline or during the meeting?) would be "current best practices for 'v2' specs"? > > / Jonas > >
[IndexedDB] Transaction ordering for readonly transactions
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
