Linux FC2 TC 5.0.28 I'm not storing a db object within a session although I am storing objs within the session(of course - session.setAttribute). However, I have references to them from the controller so that shouldn't be the problem... eh?
An interesting thing, I sometimes have to reboot my machine, not just restart TC. Although other apps run fine, I have to reboot my machine in order to get TC up again. I optimized my db connection, I did have it in servlet init(). Although I knew I had to do this and I'm much better off for it, and I appreciate you're noting it, but this didn't eliminate the crashing problem. I also am now taking advantage of a connection pool. However, as you figured, that does not solve the crash problem. Finally, I removed the <session-config><session-timeout> element from myapp web.xml to test if this is the initiator of the problem. Let you know what I find. Still, even if this is what initiates the sequence leading to a crash, it shouldn't so something need be fixed/optimized. Any other ideas? Eric On Fri, 5 Nov 2004 13:03:27 -0000, Steve Kirk <[EMAIL PROTECTED]> wrote: > > > > > > -----Original Message----- > > From: Eric Wulff [mailto:[EMAIL PROTECTED] > > Sent: Friday 05 November 2004 07:01 > > To: Tomcat Users List > > Subject: session-timeout means tomcat restart > > > > > > Hi, I'm experiencing 2 interesting problems that may be related to my > > session timeout. > > > > 1. It seems that when my session times out I need to restart tomcat, > > often just the application via reload in the manager, in order to gain > > access to my db again. Could this be because I've been accessing the > > db via jdbc hard coded in the servlet? Might using a datasource > > connection pool take care of this? > > I would say that rather than the problem being JDBC hardcoded in the > servlet, the problem is more likely to be _how_ that code is written. > > if it really is the session timeout that is causing this, it sounds to me > like you are storing the database objects within a session object (which > seems a bit unusual). or at least the last reference to them is stored > there, so that when the session is destroyed, the database connection is > lost. it might be better to store the objects in local variables within > doPost if your servlet is simple, or if it's more complex, then perhaps > better places to put them would be the servlet context, or a field of the > servlet class/instance. it all depends on your particular situation. > whichever you choose though, you must make sure that connections are closed > (or returned to the pool) when you have finished with them. this generally > involves careful use of try/catch/finally. > > if restarting the webapp fixes the problem, it could be that your database > objects are initialised in the servlet init() method, which is then called > again when the webapp restarts. but if this were the case then I'm not sure > how session timeout could cause the problem that you describe. > > datasource connection pooling is not necessarily the answer. you can still > use up all your database resources and/or leave them hanging whether you > pool them or not! > > > 2. Often tomcat hangs without responding at all, to static or dynamic > > requests, after it's been left for an hr or more with no interaction. > > Might this be related to the memory leaks I hear about? > > you don't say which platform/ versions you are using so memory leaks are > hard to comment on. IMHO the issues above are more likely to be the problem > so check those first before suspecting an error in TC :) > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]