[IndexedDB] IDBRequest.abort on writing requests

Hi All,

Sorry if this is something that I've brought up before. I know I meant
to bring this up in the past, but I couldn't find any actual emails.

One thing that we discussed while implementing IndexedDB was what to
do for IDBRequest.abort() or "writing" requests. For example on the
request object returned from IDBObjectStore.remove() or
IDBCursor.update().

Ideal would of course be if it would cancel the write operation,
however this isn't always possible. If the call to .abort() comes
after the write operation has already executed in the database, but
before the 'success' event has had a chance to fire. What's worse is
that other write operations might already have been performed on top
of the aborted request. Consider for example the following code:

req1 = myObjectStore.remove(12);
req2 = myObjectStore.add({ id: 12, name: "Benny Andersson" });
.... do other stuff ....
req1.abort();

In this case, even if the database supported aborting a specific
operation, it's very hard to say what the correct thing to do with
operations performed after it. As far as I know, databases generally
don't support rolling back a given operation, only rolling back to a
specific point, i.e. rolling back a given operation and all operations
performed after it.

We could say that abort() signals some sort of error if the operation
has already been performed in the database, however that makes abort()
very racy.

Instead we concluded that the best thing to do was to specify that
IDBRequest.abort() should throw if called on a modifying request. If
this sounds good I'll make this change to the spec.

/ Jonas

Received on Tuesday, 13 July 2010 19:26:39 UTC