Bug 22540 - Fire event when database connection is closed without explicit close() call
Fire event when database connection is closed without explicit close() call
Status: RESOLVED LATER
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API
unspecified
All All
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-02 22:09 UTC by Joshua Bell
Modified: 2014-03-20 18:42 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2013-07-02 22:09:20 UTC
NOTE: the following is a proposal for a future version of IndexedDB

Just as an event is fired at a transaction when the transaction implicitly aborts (but not when abort() is called), there are cases where a database connection may close even without close() being called, and script should be notified with an event.

Scenarios:

* the user invokes the browser's "clear my stored data" option which deletes the backing store

* backing store is on a removable storage medium; the browser detects when the medium is removed and further read/write attempts to the database will fail (while file handles will be lost, arguably the implementation could do some magic in this scenario to reestablish the connection behind the scenes, simply failing any attempted transactions with UnknownError in the mean time)

Proposal:

If the connection to the database is closed other than by a call to close():
1. set the /closePending/ flag of /transaction/
2. for each transaction created using /connection/ that is not complete, run the steps for aborting the transaction with /transaction/ and "AbortError"
3. fire a "connectionclosed" event at /connection/; the event does not bubble and is not cancelable
Comment 1 Joshua Bell 2013-07-02 22:23:28 UTC
FWIW, various other things in the platform already fire "close" events; given that this event is fired at a connection object, that's probably a bettername.
Comment 2 Joshua Bell 2013-07-02 23:32:36 UTC
step 1 should be: set the /closePending/ flag of /connection/

Also, it should be made clear that this does not apply to connections closed via GC, context destruction, etc.

Thanks, Kyle!
Comment 3 Joshua Bell 2013-07-12 19:20:15 UTC
One bit of developer feedback already - this should include a message indicating the reason for the closure. (e.g. user deleted the backing store, I/O error, etc)

There's no generic |message| property on Event, so either we need to define a custom Event type or add one to DOM Event.
Comment 4 Chris Mumford 2014-02-18 23:01:11 UTC
Regarding Josh's suggestion for a closure reason, here's my proposal.

== Scenarios ==

Use case #1 - Normal closure caused by page

In this case the web page will:

1. Open a connection to database.
2. Register a close event handler.
3. Optionally read/write data from/to the database.
4. Script calls close() on the IDBDatabase connection object.

Use case #2 - Normal closure caused by browser

In this case the web page will:

1. Open a connection to database.
2. Register a close event handler.
3. Optionally read/write data from/to the database.

When the database is open the user will then:

1. Display browser settings.
2. Choose to clear client data (like "Clear cookies and other site data").

In this use case the page did not initiate the closure.

Use case #3 - Error in backing store forced closure.

In this case the web page will:

1. Open a connection to database.
2. Register a close event handler.
3. Read/write data from/to the database.

During the execution of the reads/writes in step #3 the backing store encountered an error which requires the connection to be closed.

== Proposal ==

The proposed solution is to fire a "close" event at the IDBDatabase object, as previously suggested, but the event will implement the new IDBConnectionCloseEvent interface

interface IDBConnectionCloseEvent : Event {
    readonly    attribute DOMString      reason;
    readonly    attribute DOMString      message;
};

The values for these attributes are as follows.

reason:
-------
"closed"
"user"
"error"

message:
--------
This would contain any additional information the browser may want to supply. Some examples might be:

  "Closed by page"
  "Deleted all user data"
  "Database corrupt: Checksum mismatch"
Comment 5 Joshua Bell 2014-03-20 18:42:00 UTC
Any opinions on cmumford's proposal?

Chrome is already firing a close event in the abnormal case per my description (and refined by comments 1-2), but it doesn't introduce a new type to the platform and since it's abnormal-close only it can't be relied upon by pages.