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


Reply via email to