On 13.07.2009 11:31, Raphael Neve wrote: > > Rainer Jung-3 wrote: >> >> [...] >> >> Yup, and the code run by the finalizer makes a network call (likely to >> the database), which seems to be a very bad pattern. Finalizers are not >> a great idea by themselves, but one needs to keep them as simple as >> possible. Doing network communication in a finalizer doesn't sound right. >> >> Looks like you should check the firebird bug database and/or open an >> issue there. >> >> > > Well, I must plead guilty, I am the author of the fr.microtec.db.* packages > which are basically wrappers around JDBC concepts to make things a bit > easier (a Query object that handles macros, etc.). > I ran into trouble once with some database resources that weren't getting > released (java.sql.PreparedStatement and java.sql.ResultSet) so I made sure > that my code always had a finally block in it to close() the statements and > resultset, and as an added caution, I made a call to a "cleanup" method in > the finalizer of my Query object that released those resources in case they > hadn't been released. I figured this was a good idea in case I ever forgot > to free the resources in my code, then when the garbage collector came > around he would trigger the release of the resources. Is that wrong ? I > suppose I should not rely on the finalizer for this task ? But then what is > the best way to handle this ? How can I put in place a mecanism to securize > my application in this area ? > > Thanks for you insights, > Raphael
You might want to look at Bloch's book "Effective Java", which has a section called "Avoid finalizers". The page http://java.sun.com/developer/technicalArticles/javase/finalization/ also has some introductory material. The dbcp pool for instance has a mechanism which checks for non-closed connections (abanoned connections) and forcibly closes them. The way it tracks them, is taking a timstamp when they got returned by the pool to the app and simply checking, whether a connection stays outside of the pool for to long. In some cases this is adequate. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
