Thanks David. I went through JDBCMailRepository and added finally blocks to close no matter what.
Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ ----- Original Message ----- From: "David Sitsky" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 24, 2001 2:59 AM Subject: Re: JDBCMailRepository connection leak? > Actually... its not a connection leak (my apologies). I was used to an > environment where there was a connection pool, so the connection itself > was never GCed since there was a reference to it... :) > > In this case, there won't be a reference to c, so the resources will get > cleaned up when the object is GCed (whenever that will be). Still > probably better style to use finally() though.. > > Cheers, > David > > On Wednesday 24 October 2001 17:09, David Sitsky wrote: > > G'day, > > > > I was browsing though JDBCMailRepository.java, and noticed in many of > > the methods (store, retrieve, remove, list), a JDBC connection is > > obtained, but in the event of an exception being thrown, the connection > > isn't closed in the catch() block, which will result in a connection > > leak, since connection.close() isn't called, although the connection > > object be garbage collected of course. > > > > The code should be refactored to have a finally() block so that the code > > looks like: > > > > method() > > { > > try > > { > > Connection c = getConnection(); > > > > ... > > } > > catch (Exception e) > > { > > ... > > } > > finally > > { > > c.close(); > > } > > } > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
