Yes yes! The finally block has got to be it! I was closing the connection just before returning a user, forgetting that if authorization failed I would never get far enough in the code to close the connection and return the user.
That explains a lot. Today, I rewrote all my database access methods to open and close their own connections (instead of one connection per user session). After I did this, I was able to make more than 8 requests in the case of a *sucessful* login (using the back button and re-entering the password). However, in the case of an unsuccessful login, (where my authentication method throws an error if the password doesn't match the db password), it still only gave me 8 tries. This must have been because I was throwing the error before I got to the _conn.close() line in my authentication method. So, the finally block *must* be the solution. I can't wait to try it tomorrow. I'm sure that things will now work in the case of successful or unsuccessful logins. I will let you know! 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]
