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