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]