W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: [IndexedDB] Transaction ordering for readonly transactions

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 10 Mar 2014 13:29:46 -0700
Message-ID: <CA+c2ei_=tf7w73u+PQjNj2UDnt5ru+QJMMPTCtz129k-KQJdDg@mail.gmail.com>
To: Joshua Bell <jsbell@google.com>
Cc: Webapps WG <public-webapps@w3.org>
On Mar 10, 2014 10:35 AM, "Joshua Bell" <jsbell@google.com> 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
Received on Monday, 10 March 2014 20:30:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC