- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 12 Aug 2010 14:56:24 -0700
- To: Nikunj Mehta <nikunj@o-micron.com>
- Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Webapps WG <public-webapps@w3.org>
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, 12 August 2010 21:57:23 UTC