On Apr 21, 2010, at 5:11 PM, Jeremy Orlow wrote: > On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta <nik...@o-micron.com> wrote: > > On Mar 15, 2010, at 10:45 AM, Jeremy Orlow wrote: > >> On Mon, Mar 15, 2010 at 3:14 PM, Jeremy Orlow <jor...@chromium.org> wrote: >> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta <nik...@o-micron.com> wrote: >> On Feb 18, 2010, at 9:08 AM, Jeremy Orlow wrote: >>> 2) In the spec, dynamic transactions and the difference between static and >>> dynamic are not very well explained. >> >> Can you propose spec text? >> >> In 3.1.8 of http://dev.w3.org/2006/webapi/WebSimpleDB/ in the first >> paragraph, adding a sentence would probably be good enough. "If the scope >> is dynamic, the transaction may use any object stores or indexes in the >> database, but if another transaction touches any of the resources in a >> manner that could not be serialized by the implementation, a RECOVERABLE_ERR >> exception will be thrown on commit." maybe? >> >> By the way, are there strong use cases for Dynamic transactions? The more >> that I think about them, the more out of place they seem. > > Dynamic transactions are in common place use in server applications. It > follows naturally that client applications would want to use them. > > There are a LOT of things that are common place in server applications that > are not in v1 of IndexedDB. > > Consider the use case where you want to view records in entityStore A, while, > at the same time, modifying another entityStore B using the records in > entityStore A. Unless you use dynamic transactions, you will not be able to > perform the two together. > > ...unless you plan ahead. The only thing dynamic transactions buy you is not > needing to plan ahead about using resources. > > The dynamic transaction case is particularly important when dealing with > asynchronous update processing while keeping the UI updated with data. > >> >> >> Background: Dynamic and static are the two types of transactions in the >> IndexedDB spec. Static declare what resources they want access to before >> they begin, which means that they can be implemented via objectStore level >> locks. Dynamic decide at commit time whether the transaction was >> serializable. This leaves implementations with two options: >> >> 1) Treat Dynamic transactions as "lock everything". > > This is not consistent with the spec behavior. Locking everything is the > static global scope. > > I don't understand what you're trying to say in the second sentence. And I > don't understand how this is inconsistent with spec behavior--it's simply > more conservative. > > >> >> 2) Implement MVCC so that dynamic transactions can operate on a consistent >> view of data. (At times, we'll know a transaction is doomed long before >> commit, but we'll need to let it keep running since only .commit() can raise >> the proper error.)
MVCC is not required for dynamic transactions. MVCC is only required to open a database in the DETACHED_READ mode. Since locks are acquired in the order in which they are requested, a failure could occur when an object store is being opened, but it is locked by another transaction. One doesn't have to wait until commit is invoked. >> >> Am I missing something here? >> >> >> If we really expect UAs to implement MVCC (or something else along those >> lines), I would expect other more advanced transaction concepts to be >> exposed. What precisely are you referring to? Why are these other more advanced transaction concepts required? >> If we expect most v1 implementations to just use objectStore locks and thus >> use option 1, then is there any reason to include Dynamic transactions? Why do you conclude that most implementations just use object store locks? >> >> J > > Can you please respond to the rest? I really don't see the point of dynamic > transactions for v1. There has been previous discussions on this DL about the need for dynamic locking [1], MVCC [2] and incremental locking [3] . Did you have anything new to add to that discussion? [1] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0197.html [2] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0322.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1080.html
