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

Re: [IndexedDB] IDBRequest.abort on writing requests

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 13 Jul 2010 21:17:33 +0100
Message-ID: <AANLkTindl7wZkSGXermvmqYaWYgpUnkq5GQiO4FYry56@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
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.

Received on Tuesday, 13 July 2010 20:18:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC