[concurrency-interest] Revisit of the early GC issue that Hans brought up

Jeremy Manson jeremy.manson at gmail.com
Wed Mar 25 14:17:52 EDT 2009

My recollection is that the easiest way to prohibit this behavior is
by placing a reference to mgr somewhere in the heap, where it can be
accessed by following a chain of references from a static field.

However, it seems to me that you would want to use synchronization to
make sure that you were done with the connection before it could be
finalized.  I, personally, would go with the synchronization solution.


On Tue, Mar 24, 2009 at 7:52 AM, Gregg Wonderly <gregg at cytetech.com> wrote:
> I have a JDBC factory/connection caching class which I've used for more than
> a decade.  Its basic usage is something like
> DatabaseManager mgr = SQLFactory.getConnection( url, driver, user, passwd );
> try {
>        ResultSet rs = mgr.executeQuery(...);
>        while( rs.next() ) {
>        }
>        rs = mgr.executeQuery( ... );
>        if( rs.next() == false ) {
>                mgr.executeUpdate(...);
>        }
> } finally {
>        // close Statement, ResultSet etc., but cache the Connection.
>        mgr.release();
> }
> It tracks all ResultSet and Statement usage internally and closes things
> before creating new ones to eliminate all the try{} finally{
> closeSomething() } nesting
> that is typically necessary.
> Recently, while using this in another project, a new developer on my team
> had some complex code where a long lived bug was causing some stale
> Connection objects to not be closed correctly.  I decided to introduce the
> use of my ReferenceTracker class to manage the closing of those "lost"
> Connection instances.
> What I found, was that this mostly worked, except that the behavior which
> Hans detailed about premature GC became visible, and connections where
> getting "freed" before the mgr.release() call had been made, and the GC path
> into the release of those objects was causing Connections to be
> aborted/closed before the mgr.release() call occured.
> So, I had to take that back out, and I'm trying to decide if there is a way
> to still make this work without massive changes in code already using this
> class to add synchronized( mgr ){} everywhere.
> Gregg Wonderly
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list