W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

[indexeddb] Client API state after calling trasnaction.abort

From: Israel Hilerio <israelh@microsoft.com>
Date: Wed, 13 Jul 2011 02:23:29 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
CC: David Sheldon <dsheldon@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D1922C3@TK5EX14MBXC119.redmond.corp.microsoft.com>
A couple of questions regarding client state vs. server state on several calls.  What should be the client behavior for subsequent calls after a transaction abort is called?  This assumes the server request hasn't been processed yet.  For example:

1.        var txn = db.transaction([osName], IDBTransaction.READ_WRITE);
2.        objStore = txn.objectStore(osName);
3.        var rq = objStore.add(books[2]).onsuccess = function (e1) { log("added book 2"); };
4.        txn.abort();
5.        try {
6.        	   var rq2 = objStore.add(books[3]).onerror = function (e2) { log("failed to add book 3"); };
7.        catch (ex) {
8.	   log ("TRANSACTION_INACTIVE_ERR");
9.        }

I expect that line #3 will receive the success event.  However, I expect that rq2 will throw a TRANSACTION_INACTIVE_ERR that will be processed by line #7 and that the onerror function will never be called on line #6.  My assumption is that even if the transaction abort hasn't been processed by the server, that the client state associated with the transaction will contain an invalid transaction and thus fail.

Do you agree?

Israel
Received on Wednesday, 13 July 2011 02:23:58 GMT

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