Hi Guys, Think I know the answer off the top of my head, but will dig into the code this afternoon to just be sure.
Enjoy, Mike On 7/21/07, Roland Weber <[EMAIL PROTECTED]> wrote:
Hi Mike, Oleg, all, I need some advice on TSCCM garbage collection. I think I have the connection GC covered, but there's also the GC of the connection manager itself. Based on some comments in the code, I believe there are two cases: 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. 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. I am considering to move the TSCCM into a separate package o.a.h.i.conn.tsccm, so I can factor out some TSCCM specific classes without cluttering the main implementation package. There are way too many nested classes to feel comfortable with. This would also create a home for some stuff elsewhere which looks generic but is really tailored for the TSCCM, such as the current selection of parameters. Oleg, I'm glad you asked me to port the unit tests before starting the refactoring. These things are much easier to debug one at a time, while I am making the changes. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
