Re: [IndexedDB] Do we need a timeout for VERSION_CHANGE?
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. J On Wed, Dec 15, 2010 at 10:46 PM, Pablo Castro pablo.cas...@microsoft.comwrote: Regular transactions take a timeout parameter when started, which ensures that we eventually make progress one way or the other if there's an un-cooperating script that won't let go of an object store or something like that. I'm not sure if we discussed this before, it seems that we need to add a similar thing for setVersion(), and it's basically a way of starting a transaction. I was thinking we could have an optional timeout argument in setVersion with a UA-specific default. In the async case we would fire the onerror event and in the sync case just throw, both with TIMEOUT_ERR. Thanks -pablo
RE: [IndexedDB] Do we need a timeout for VERSION_CHANGE?
From: jor...@google.com [mailto:jor...@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. Thanks, -pablo
[IndexedDB] Do we need a timeout for VERSION_CHANGE?
Regular transactions take a timeout parameter when started, which ensures that we eventually make progress one way or the other if there's an un-cooperating script that won't let go of an object store or something like that. I'm not sure if we discussed this before, it seems that we need to add a similar thing for setVersion(), and it's basically a way of starting a transaction. I was thinking we could have an optional timeout argument in setVersion with a UA-specific default. In the async case we would fire the onerror event and in the sync case just throw, both with TIMEOUT_ERR. Thanks -pablo
