W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Thu, 16 Dec 2010 22:09:38 +0000
To: Jeremy Orlow <jorlow@chromium.org>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E0624000D0@TK5EX14MBXC128.redmond.corp.microsoft.com>

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. 

Received on Thursday, 16 December 2010 22:10:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC