Re: [IndexedDB] Do we need a timeout for VERSION_CHANGE?

On Thu, Dec 16, 2010 at 4:39 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Dec 16, 2010 at 10:09 PM, Pablo Castro <Pablo.Castro@microsoft.com>
> wrote:
>>
>> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy
>> Orlow
>> Sent: Thursday, December 16, 2010 2:35 AM
>>
>> >>In another thread (in the last couple days) we actually decided to
>> >> remove timeouts from normal transactions since they can be implemented as a
>> >> setTimeout+abort.
>> >>
>> >>But I agree that we need a way to abort setVersion transactions before
>> >> getting the callback (so that we implement timeouts for them as well).
>> >>  Unfortunately, I don't immediately have any good ideas on how to do that
>> >> though.
>>
>> Sorry, forgot to qualify it, context == sync api. I assume that the sync
>> versions of the API will truly block, so setTimeout won't do as code won't
>> just reenter into the timeout callback while blocked on a sync IndexedDB
>> call, are we all on the same page on that? If that's the case, then I don't
>> think we can remove the timeout parameter from the sync versions of
>> transaction() and setVersion(). Does that sound reasonable? I'll add them
>> for now, we can adjust if somebody come up with a better approach.
>>
>> As for setVersion in async...that's actually a problem as well now that I
>> think about it because you don't have access to the (version) transaction
>> object until it actually was able to start. One option besides having a
>> timeout parameter in the method would be to have an abort() method in
>> IDBVersionChangeRequest.
>
> Very good points....
> Given the fact that we will need timeouts for the sync version, I'm starting
> to wonder if it makes sense to just leave in for the async version.  Hm...
>  Jonas, what do you think?

I'm fine with that, but I still don't think we should introduce the
options object, given how rarely the timeout parameter is likely to be
used.

/ Jonas

Received on Friday, 17 December 2010 17:57:30 UTC