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

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