Re: [IndexedDB] IDBRequest.abort on writing requests

On Tue, Jul 13, 2010 at 8:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

I'd be fine with that.

Or we could remove abort all together.  I can't really think of what types
of operations you'd really want to abort until (at least) we have some sort
of join language or other mechanism to do really expensive read-only calls.

Or we could take abort off IDBRequest and instead put a rollback on
transactions (and not do the modify limitation).  That way if something's
taking too long, you can say rollback.  We'd be assured of getting back to
a consistent point in time and it'd of course stop execution.

J