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

[IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 12 Aug 2010 21:22:30 +0000
To: Webapps WG <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E05901C404@TK5EX14MBXC126.redmond.corp.microsoft.com>
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). 

Thanks
-pablo
Received on Thursday, 12 August 2010 21:23:06 GMT

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