RE: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
The changes suggested in bug 10357 were made. I pushed them up and can be merged the next time Nikunj builds an editor's draft. Thanks, Eliot -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Thursday, August 12, 2010 2:56 PM To: Nikunj Mehta Cc: Pablo Castro; Webapps WG Subject: Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions On Thu, Aug 12, 2010 at 2:46 PM, Nikunj Mehta nik...@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
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
On Thu, Aug 12, 2010 at 10:22 PM, Pablo Castro pablo.cas...@microsoft.comwrote: 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? Yup. 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. J
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
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.
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
On Thu, Aug 12, 2010 at 2:46 PM, Nikunj Mehta nik...@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
