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]

Reply via email to