struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pingili, Madhupal" <>
Subject RE: Connecting to a database during sessionDestroyed(HttpSessione vent) in HttpSessionlistener class
Date Mon, 26 Jul 2004 14:52:30 GMT

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
   these background processes like listeners need a connection from the same

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.

Reddy Pingili 

> -----Original Message-----
> From:	Geeta Ramani []
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message