Subject New API: Object Life Time
Author Jim Starkey
The last draft of the specification had somewhat of a muddle
over object lifetime. Some classes had a close(), others had
addRef() and release(), and some lucky ones had both. After
pondering the issue, I've got a proposal:

Object life times are managed with addRef() and release(). When
the use count (decremented by release()) goes to zero, the object
joins the great bit bucket in the sky.

The method close(), when present, can be used to release any context
or resources associated with the object but without deleting the

All objects are automatically closed, if necessary, prior to

A parent object, when deleted, takes its children with it. Releasing
a PreparedStatement would automatically delete all ResultSets. Releasing
a Connection object would delete everything associated with the connection.

Releases (other than the Connection object) are not necessary to
prevent memory leaks but only to control memory usage.

I will also redefine release() to return the post release use
count of the object. A return of zero means the object is history.
A client that wants to force release must loop decrementing the
use count to zero.

For example, the Connection object is allocated, unconnected, by
createConnection() then activated by openDatabase(). Connection::close()
would close the connection, freeing the Connection object for another
connection. Connection::release() (assuming no intervening addRef()s)
would close the connection and delete the object.

Comments? Questions? Bickering? Seconds may call at 40 Beach St.,
Manchester, MA, during normal programmer hours...

Jim Starkey