W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

[IDB] Lifetime of IDB objects

From: João Eiras <joaoe@opera.com>
Date: Mon, 22 Oct 2012 01:01:08 +0100
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <op.wmjzn6qg2q99of@coruscant>

Hi !

The specification does not specify in detail what happens to several of  
the object types once they have reached their purpose.

For instance, IDBTransaction's abort and objectStore methods dispatch  
InvalidStateError.

However, IDBRequest and IDBCursor have properties which return other  
objects like IDBRequest.source, IDBRequest.result, IDBRequest.transaction,  
IDBCursor.source, IDBCursor.key, IDBCursor.primaryKey which behavior,  
after the request has completed, is undefined or defined as returning the  
same value (for source only it seems).

Having these objects keeping references to other objects after they have  
completed, can represent extra memory overhead, while not very useful,  
specially if the application is data heavy, like an offline main client  
with lots of requests, or long blobs are used, and it prevents the garbage  
collector from cleaning up more than it could, specially while a  
transaction is active.

I suggest that after an IDBRequest, IDBTransaction or IDBCursor complete,  
all their properties are cleared (at least the non-trivial ones) so the  
garbage collector can do it work. However, since that would cause the  
properties to return later undefined/null, it is better if they just all  
throw InvalidStateError when accessed after the object has reached it's  
purpose.

Btw, an error in http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-source  
"This function never returns null or throws an exception". Should be "This  
property".

Thank you.
Received on Monday, 22 October 2012 00:01:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT