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

Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 12 Aug 2010 22:41:43 +0100
Message-ID: <AANLkTi=oWS8sT43srmruUvnDN-tNEh4d-3THkUhirGvO@mail.gmail.com>
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: Webapps WG <public-webapps@w3.org>
On Thu, Aug 12, 2010 at 10:22 PM, Pablo Castro

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


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).

This seems reasonable to me.

Received on Thursday, 12 August 2010 21:42:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:26 UTC