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

Ping?

On Mon, Mar 15, 2010 at 10:45 AM, Jeremy Orlow <jorlow@chromium.org> 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.
>
>
> 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".
>
> 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
>