W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

RE: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions

From: Eliot Graff <eliotgra@microsoft.com>
Date: Thu, 30 Sep 2010 18:06:29 +0000
To: Jonas Sicking <jonas@sicking.cc>, Nikunj Mehta <nikunj@o-micron.com>
CC: Pablo Castro <Pablo.Castro@microsoft.com>, Webapps WG <public-webapps@w3.org>
Message-ID: <CE3A5BFD1228D84A8D9C158EEC195FD50EBC5231@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
The changes suggested in bug 10357 were made. I pushed them up and can be merged the next time Nikunj builds an editor's draft.

Thanks,

Eliot

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
Sent: Thursday, August 12, 2010 2:56 PM
To: Nikunj Mehta
Cc: Pablo Castro; Webapps WG
Subject: Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions

On Thu, Aug 12, 2010 at 2:46 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> On Aug 12, 2010, at 2:22 PM, Pablo Castro wrote:
>
>> We currently have two read-only transaction modes, READ_ONLY and SNAPSHOT_READ. As we map this out to implementation we ran into various questions that made me wonder whether we have the right set of modes.
>>
>> It seems that READ_ONLY and SNAPSHOT_READ are identical in every aspect (point-in-time consistency for readers, allow multiple concurrent readers, etc.), except that they have different concurrency characteristics, with READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers come and go while readers are active. Does that match everybody's interpretation?
>
> That is the intention.

That was my understanding too.

>> Assuming that interpretation, then I'm not sure if we need both. Should we consider having only READ_ONLY, where transactions are guaranteed a stable view of the world regardless of the implementation strategy, and then let implementations either block writers or version the data? I understand that this introduces variability in the reader-writer interaction. On the other hand, I also suspect that the cost of SNAPSHOT_READ will also vary a lot across implementations (e.g. mvcc-based stores versus non-mvcc stores that will have to make copies of all stores included in a transaction to support this mode).
>
> The main reason to separate the two was to correctly set expectations. It seems fine to postpone this feature to a future date.

Sounds good to me.

/ Jonas
Received on Thursday, 30 September 2010 18:07:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT