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.
- [IDB] Lifetime of IDB objects João Eiras
-
