Jim,

>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.

addRef - decRef, attach - detach, ... - release

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

flush() is better in such context.

>All objects are automatically closed, if necessary, prior to
>deletion.

Agreed.

>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.

Good if you are still determined to bother with pointers and deleting them
properly.
I still vote for any destructive action to be placed in destructor
(in a place for destructive actions to take place)

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

Ok.

>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.

Oops! This will violate the other client's rights to the object!
What is the reason for client to want to force the delete?

>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.

Jim, I have something deep inside me against having
Connection object in "unconnected" mode!
The fact that Connection object is created should
MEAN - we are connected!
Please, avoid object modes if possible.

Glebas