- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Sat, 10 Jul 2010 00:51:56 +0530
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Andrei Popescu <andreip@google.com>, public-webapps <public-webapps@w3.org>
On Jul 8, 2010, at 12:38 AM, Jonas Sicking wrote:
>>>>>
>>>>> One of our main points was to make getting objectStore
>>>>> objects a synchronous operation as to avoid having to nest multiple
>>>>> levels of asynchronous calls. Compare
>>>>>
>>>>> var req = db.openObjectStore("foo", trans);
>>>>> req.onerror = errorHandler;
>>>>> req.onsuccess = function(e) {
>>>>> var fooStore = e.result;
>>>>> var req = fooStore.get(12);
>>>>> req.onerror = errorHandler;
>>>>> req.onsuccess = resultHandler;
>>>>> }
>>>>>
>>>>> to
>>>>>
>>>>> var fooStore = db.openObjectStore("foo", trans);
>>>>> var req = fooStore.get(12);
>>>>> req.onerror = errorHandler;
>>>>> req.onsuccess = resultHandler;
>>>>>
>>>>>
>>>>> I also don't understand the advantage of having the transaction as an
>>>>> argument to openObjectStore rather than having openObjectStore live on
>>>>> transaction. Compare
>>>>>
>>>>> db.openObjectStore("foo", trans);
>>>>>
>>>>> to
>>>>>
>>>>> trans.openObjectStore("foo");
>>>>>
>>>>> I also don't understand the meaning of specifying a mode when a
>>>>> objectStore is opened, rather than specifying the mode when the
>>>>> transaction is created.
>>>>
>>>> Have you reviewed the examples? Different object stores in a transaction
>>>> are
>>>> used in different modes, and that requires us to identify the mode when
>>>> opening the object store. This also increases concurrency. This is
>>>> particularly useful for dynamic transactions.
>>>
>>> I'm following you better now. I do see how this can work for dynamic
>>> transactions where locks are not acquired upon creation of the
>>> transaction. But I don't see how this makes sense for static
>>> transactions. And it indeed seems like you are not using this feature
>>> for static transactions.
The feature is targeted for use in dynamic scope.
>>>
>>
>> I don't think it's even possible with the current API since
>> openTransaction() takes a list of objectStore names but a single mode.
>
> Indeed. We could allow static transactions to use different lock
> levels for different objectStores, all specified when the
> IDBTransaction is initially created. It's just a matter of syntax to
> the IDBDatabase.transaction() function. However so far I've thought
> that we should leave this for v2. But if people would feel more easy
> about dropping dynamic transactions if we add this ability, then I
> would be ok with it.
From my examples, it was clear that we need different object stores to be opened in different modes. Currently dynamic scope supports this use case, i.e., allow mode specification on a per object-store basis. Therefore, unless we decide to de-support this use case, we would need to add this ability to static scope transactions if dynamic scope transactions go out of v1.
>
>>> If it is the case that specifying a mode when opening an objectStore
>>> only makes sense on dynamic transactions, then I think we should only
>>> expose that argument on dynamic transactions.
>>>
>>> Now that I understand your proposal better, I don't understand how
>>> IDBTransaction.objectStore works for dynamically scoped transactions
>>> in your proposal. It seems to require synchronously grabbing a lock
>>> which I thought we wanted to avoid at all cost.
See below.
>>>
>>
>> This is rather confusing: is IDBTransaction::objectStore() creating an
>> object store, now? If yes, then it must lock it synchronously. If it just
>> returns an object store that was previously added to the transaction, what
>> is the 'mode' parameter for?
>
> Looking at Nikunj's example code, it seems like you can request a new
> objectStore to be locked using IDBTransaction.objectStore(). Not sure
> if that is a bug or not though?
That was a bug. For dynamic transactions, obtaining an object store would have to be asynchronous as it involves obtaining a lock.
I also did not hear from you about explicit commits. Did that mean that you agree with that part of my proposal? There are several examples where it makes sense to explicitly commit, although it is automatic in some cases.
Received on Friday, 9 July 2010 19:34:32 UTC