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

On Fri, Dec 17, 2010 at 10:05 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Fri, Dec 17, 2010 at 5:56 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> 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.
>
> I'm still not sure we should keep it.  It seems like a decent amont of API +
> implementation for a feature that can be easily emulated.  I guess we can
> keep it for now though.
> What about timeout/abort for async setVersion?  How should we allow those?
>  Have abort() and ontimeout on the IDBRequest for just setVersion + a second
> optional parameter to setVersion for the timeout?  Seems like a heavyweight
> solution, but I'm not sure how else to do it.

We already have a separate IDBVersionChangeRequest interface, so
adding ontimeout and abort() there should work.

/ Jonas

Received on Friday, 17 December 2010 18:27:55 UTC