Re: [IndexedDB] Dynamic Transactions (WAS: Lots of small nits and clarifying questions)

On Mon, Apr 19, 2010 at 11:44 PM, Nikunj Mehta <nikunj@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 <jorlow@chromium.org> wrote:
>
>> On Sat, Mar 13, 2010 at 9:02 AM, Nikunj Mehta <nikunj@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.)
>
> 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.  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?
>
> J
>
> Can you please respond to the rest?  I really don't see the point of
dynamic transactions for v1.