Hello Thanks to all These answers give me some ideas to verify the developer's code I 'll try to set a session listener Sorry for the connection : the application's security is coded in the database by using Oracle's role and we can't use pool connection
Jean-Claude -----Message d'origine----- De : Tobias Meyer [mailto:[EMAIL PROTECTED] Envoyé : lundi 13 mars 2006 18:16 À : Tomcat Users List Objet : Re: Time out on sessions with AJP13 Yes I also think he should implement something like this: public class SessionListener implements HttpSessionBindingListener, HttpSessionActivationListener, Serializable { ... public void valueUnbound(HttpSessionBindingEvent event) { <put code to release connection here> } ... } and put one of those in each session that has a gets an connection. Tobias Earnie Dyke wrote: >Chuck makes a good point about the overhead of the finalize() method. I think the problem was however not with open result sets and statements but with a connection itself. Using a finally clause to ensure that result sets and statements are closed is a must but it the intention is to persist an open database connection, finally will not help. > >Perhaps a Session Listener would solve the problem. > >Earnie! > >-----Original Message----- >From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] >Sent: Monday, March 13, 2006 10:01 AM >To: Tomcat Users List >Subject: RE: Time out on sessions with AJP13 > > > > >>From: Earnie Dyke [mailto:[EMAIL PROTECTED] >>Subject: RE: Time out on sessions with AJP13 >> >>You should consider implementing the finalize() method in >>your session bean to close the connection nicely. >> >> > >If there's any possible way of avoiding finalize(), don't use it. The >presence of a finalize() method requires special handling (much slower) >during object allocation, and there's no guarantee that the method will >_ever_ be called. It's a really, really bad idea. > >What you should be using is finally clauses for all your connection >manipulation to make sure that result sets, statements, and connections >are logically closed after use. > > - Chuck > > >THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >MATERIAL and is thus for use only by the intended recipient. If you >received this in error, please contact the sender and delete the e-mail >and its attachments from all computers. > >--------------------------------------------------------------------- >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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]