Re: [IndexedDB] blocked event could be an error

On Thu, Jul 26, 2012 at 2:59 PM, David Grogan <dgrogan@chromium.org> wrote:
>
>
> On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal <odinho@opera.com>
> wrote:
>>
>> There are some open issues in the spec that has been there a long time.
>> They deal with opening and deleting database.
>>
>>
>>
>> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-deleting-a-database
>>
>> # 7. Wait until all objects in openDatabases are closed and all of their
>> #    transactions are finished.
>> #
>> #    ISSUE: Should we allow blocked to be fired here too, if waiting takes
>> #    "too long"?
>> #
>> # 8. Delete db.
>>
>>
>>
>> http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-running-a--versionchange--transaction
>>
>> # 4. Wait until either all objects in openDatabases are closed and all of
>> #    their transactions are finished.
>> #
>> #    ISSUE: If .close() is called immediately but a transaction associated
>> #           with the connection keeps running for a "long time", should we
>> #           also fire a blocked event?
>> #
>> #    ISSUE: If, while we're waiting here, someone calls open with a
>> #           version number higher than version, we should probably let
>> #           that upgrade run first and bail here if it was successful.
>>
>>
>>
>> To be very honest, the whole blocked and then wait-system seems very over
>> the top for a small benefit. IMHO the harm is greater than any potential
>> small benefit. We'd have to keep lots of requests indefinitely open.
>>
>> If the other page having an open database doesn't clean up and db.close()
>> in its db.versionchange handler, most definitely the developer haven't
>> ever thought about the case. I see no benefit in waiting for that to
>> happen. And the page that is being blocked, also has no way to abort/close
>> its own request if you were to follow spec because transaction is not set
>> until after blocked has run(!).
>
>
> We've also received comments from internal development teams about this
> issue.  The devs didn't like having an outstanding request that may or may
> not ever receive a success event. They planned on cancelling their open
> request if they got a blocked event but, as Odin points out, quickly
> discovered there was no way to do so.  We've talked briefly about adding
> something like IndexedDB.openOrFail("db", high_version) that would fire a
> BlockedError if other open connections didn't close in response to
> versionchange events.

I definitely think that we need to keep the "blocked" events as
non-error events since it supports the use case of opening a
connection and displaying UI to the user asking that other tabs are
closed if the "blocked" event fires.

However the use cases brought up here makes sense. I think we can
solve this in two ways:

Add a .abort() method to IDBOpenDBRequest. This would cause an "error"
event to be fired immediately (but asynchronously) and the attempt to
open the database to be canceled.

Add a openOrFail method in addition to the existing open method.
openOrFail would automatically abort the attempt to open the database
as soon as "blocked" is fired. Instead an "error" event would
immediately be fired.


However is this something that we can wait with until v2? Punting
something to v2 doesn't mean that implementation needs to hold off
implementing until v2 is "finished", but it means that we should start
an official v2 draft sooner rather than later.

I don't have a strong opinion either way.

/ Jonas

Received on Thursday, 26 July 2012 22:20:49 UTC