W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

RE: [IndexedDB] Bug#11401 -We should disallow .transaction() from within setVersion transactions

From: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 5 May 2011 15:51:15 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D043472@TK5EX14MBXC113.redmond.corp.microsoft.com>
Resending, any comments on this?

Israel

On Tue, May 3, 2011 at 12:11 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> We expect async operations to be queue up and executed in the order in
> which they were created.  Thus, the request to create a second transaction
> inside the onsuccess handler of a setVersion request using a .transaction()
> method would fail as long as we were inside a VERSION_CHANGE transaction.
> The reason being that the VERSION_CHANGE transaction locks the complete
> db.
> 
> It seems we wouldn't want to allow this type of scenario.  Do we expect this
> to be a realistic scenario?  Is there a reason why we wouldn't just throw a
> NOT_ALLOWED_ERR.  Could we modify the transaction method information
> to say something like:
> 
> -->Throws an IDBDatabaseException of NOT_ALLOWED_ERR when the
> transaction() method is called within the onsuccess handler of a setVersion
> request.
> 
> This would simply the Async model and keep it consistent with the Sync
> model.
> 
> Israel
> 
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11401
> 
Received on Thursday, 5 May 2011 15:51:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT