Hi,

Thanks for the helpful words. Currently, I have removed my dbcp pooling
altogether and the problem went away. Now, I am trying to find a way to
bring dbcp back without causing the problem. I noticed that I was using
dbcp 1.0, so maybe switching to 1.1 will help. Thanks for the tip on
keeping connections only a short time!

Is dbcp the best connection pool for Tomcat/Apache/mysql/struts, or is
there something better? I'm having a hard time trying to figure out how to
configure it....

Best,

Heather

On Wed, 7 Jan 2004, Geeta Ramani wrote:

> Heather:
> 
> Sounds like you nailed down your problem.  You defintely do not want to hang on to a
> connection longer than absolutely necessary.  So if you get a connection from your
> pool at say the start of a database access method, make sure you release it back to
> the pool at the end of that method.  Plus make sure you place this code in a
> **finally* block - so regardless of whether or not your database query was a success,
> the connection is released to the pool..
> 
> Also the earlier suggesstion of having just one connection in the pool during
> development works perfectly - we have used it for a while now and have been able to
> uncover errors we otherwise would not have..
> 
> Good luck!
> Geeta
> 
> Heather Marie Buch wrote:
> 
> > Hi,
> >
> > PROBLEM SOLVED (sort of)
> >
> > It was because I failed to close the database connections. Well, I closed
> > them too late.
> >
> > I had things set up so that when a user logs on, a "service" object is
> > created for them. The Action servlet calls the service and receive
> > business objects. The service talks to the database and creates
> > business objects to give back to the action servlets. I had been
> > fetching a new connection from the pool upon initialization of the
> > service, and returning the connection to the pool when the
> > user logged out and the service object was destroyed.
> >
> > When I change my code so that the "service" creates a new db
> > connection each time it interacts with the db, and returns the connection
> > in the same method, the server no longer hangs. So I guess I will have to
> > change it to "one connection per query" instead of "one connection per
> > user".
> >
> > Does this sound right?
> >
> > Thanks all!
> >
> > Heather Buch
> >
> > On Tue, 6 Jan 2004, Anthony Martin wrote:
> >
> > > I've had something like that happen when I call
> > > getDataSource(request).getConnection() and forget to close them.  After a
> > > finite number of requests, the server appears to hang.  Actually, depending
> > > on the settings, it will timeout.  But how you handle the exception could
> > > prevent it from being properly reported.
> > >
> > >
> > > On 1/6/04 11:38 AM, in article
> > > [EMAIL PROTECTED], "Heather Marie
> > > Buch" <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > > Manfred Wolff wrote:
> > > >
> > > >> Heather.
> > > >>
> > > >> Have you studied the tomcat logs?
> > > >
> > > > Yes, I have. This is the only thing that is remotely interesting.
> > > > In localhost_log.2004-01-06.txt I get this:
> > > >
> > > > 2004-01-06 03:38:41 action: null
> > > > 2004-01-06 03:40:08 action: null
> > > > 2004-01-06 03:40:12 action: null
> > > > 2004-01-06 03:40:14 action: null
> > > > 2004-01-06 03:40:16 action: null
> > > > 2004-01-06 03:40:18 action: null
> > > > 2004-01-06 03:40:21 action: null
> > > > 2004-01-06 03:40:23 action: null
> > > >
> > > > (corresponding to the 8 times I try to log in). I don't really know where it
> > > > is
> > > > coming from. I would like to know what is generating the above, so I could to
> > > > in and modify the logging
> > > > statements to produce a bit more detail!
> > > >
> > > > I also have log4j statements in my own code and have been testing this. But I
> > > > can't generate any error or anything beyond the normal output, 8 times.
> > > >
> > > > What is interesting is that it always fails on the 9th try. I don't think it
> > > > is
> > > > a matter of seconds either. I have tested over a longer period (10 minutes),
> > > > but
> > > > it still gives me 8 requests before it hangs.
> > > >
> > > > And Geeta Ramani - thanks. I will take another look at the jdbc stuff!
> > > >
> > > > Best,
> > > >
> > > > Heather Buch
> > > >
> > > >
> > > >
> > > >>
> > > >> Manfred Wolff
> > > >>
> > > >> Heather Marie Buch wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> If I submit the same page more than 8 times, my server dies and I have to
> > > >>> restart. For example, the first 8 times I enter the wrong password, struts
> > > >>> will simply return me to my original form with an error message. However,
> > > >>> the 9th time - the server hangs.
> > > >>>
> > > >>> This also occurs if I enter the correct password, then press the
> > > >>> "back" button and return to the original login screen and submit again. I
> > > >>> can only repeat this 8 times. The server hangs on the 9th try.
> > > >>>
> > > >>> I am using:
> > > >>>
> > > >>> tomcat 4.1.12
> > > >>> httpd 2.0.43
> > > >>> mysql 3.23.53
> > > >>> struts 1.1
> > > >>>
> > > >>> I am not even sure if this is a struts problem. I suspect it is because I
> > > >>> tried that back  button trick with a plain old servlet, and I was able to
> > > >>> do it more than 9 times.
> > > >>>
> > > >>> Any help would be greatly appreciated! My boss wants users to be able to
> > > >>> try passwords more than 9 times!
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Heather Buch
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to