Two ideas that come to mind quickly are: 1. Adjust the pool size to a reasonable limit, keeping in mind that NOT only actual users who come to the application need a connection from pool, but also these background processes like listeners need a connection from the same pool.
2. Keep a loop while getting connection from the pool until you get a non-null connection. Then, you will always use a pooled connection. Suggestions/Corrections are welcome. HTH, Reddy Pingili > -----Original Message----- > From: Geeta Ramani [SMTP:[EMAIL PROTECTED] > Sent: Monday, July 26, 2004 9:53 AM > To: Struts Users Mailing List (E-mail) > Subject: Connecting to a database during > sessionDestroyed(HttpSessionevent) in HttpSessionlistener class > > This may be classified as OT, and if so, please ignore it or reply to me > personally. Also if this question has already been answered I would > appreciate it very much if anyone could send me a link: I can't come up > with a good search criterion to google/search for. > > I wrote a HttpSessionListener for our application and part of the > sessionDestroyed(HttpSessionEvent)code involved getting a connection from > our pool and deleting a ceratin record in a table in our database. When I > tested this code locally this worked great but when I moved this to our > server we noticed during testing that this code seemed to work > inconsistently: It seemed to be executed sometimes and not at others. > > After worrying about it over the weekend, I think I figured out the > problem: during testing we were all using the connection pool whose size > we had deliberately set to 1 to see how slow things could get. Since the > sessionDestroyed code involved getting a connection from the pool I think > it must have timed out when all of us were testing the application. In > which case, my code simply exited the try block doing nothing except log > (which was mistakenly turned off for this class (:(.. Anyways, this > explanation seems to explain everything we noticed. > > One way to solve thsi problem is to not use the pool for this part of the > app. That way it doesn't matter if there's an available connection or not, > this code will always - well, as far as possible - be executed. (In the > other parts of the app, if a connection cannot be obtained from the pool, > at least the user is made aware of it. The HttpSessionListener of course > doesn't have that luxury..) > > But I kind of feel that this is not really a clean solution..? Can > somebody comment on why I have a funny feeling about seeking this way > out..? Anybody have any better ideas on how to solve this problem? > > As always, many thanks in advance for any insights! > Geeta > > --------------------------------------------------------------------- > 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]
