hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Becke" <mbe...@gmail.com>
Subject Re: Connection Manager Garbage Collection
Date Sun, 22 Jul 2007 23:12:47 GMT
Hi Roland,

Below are some comments on your questions.

> 1. a connection is allocated. Then the TSCCM will not be
>    GCed, because an entry in REFERENCE_TO_CONNECTION_SOURCE
>    prevents it. The entry references the ConnectionPool,
>    which is a non-static nested class of the TSCCM, and
>    therefore implicitly references the TSCCM.

REFERENCE_TO_CONNECTION_SOURCE will only have a reference to a
ConnectionPool if a connection is checked out and hasn't been GCed (is
this what you mean by allocated?).  In the case when a connnection is
checked out and still active there will be many direct references to
the pool and connection manager so this shouldn't be an issue.

In the case when a connection is checked out, lost, and then GCed the
reference from the REFERENCE_TO_CONNECTION_SOURCE will eventually be
removed by the ReferenceQueueThread.

> 2. no connection is allocated. Then the TSCCM is GCed,
>    we have a unit test for this. But how are the open
>    connections closed in this scenario? I didn't see a
>    finalizer that would close them.

Currently there is nothing that closes threads other than shutdown.
Not sure if we'd want to put this in a finalizer or not.  In general I
have always avoided using them but perhaps this would be a good use
case.

I have also attached changes to the LostConnWorker that should
alleviate the issue with the GC test case.  Once this change is made I
think you'll be able to remove all of the code related to the
ReferenceQueueThread.  After that is done the only static code left is
related to ALL_CONNECTION_MANAGERS.  Is the plan to keep or remove
this code?

Mike

Mime
View raw message