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

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?

J