QM wrote:
On Thu, Mar 10, 2005 at 08:47:25PM +0100, David Causse wrote:I hope my boss didn't heard you :)
: I store my jdbc connections inside the user session, and I create thanks : to a Filter one connection per thread (cause we encountered multithread : issues with the oracle JDBC driver, and we use frames).
Is there a way to refactor your app, to move the thread-safety outside
of the Connection objects? Put another way, it sounds as though you
could insert a data layer between the Filter / Session objects and the
Connection objects.
We have about 2000jsp + 700 servlets and deployment is expected to be in june.
After some reflexion, I will use the third solution (never close connections) and try to hunt
processes that never give back the connection to the pool.
But it's strange because the connection.close() is done in the Filter in a finally{} block. Maybe
it could happen in some exceptionnal condition like OutOfMemory or hidden jsp that are
not processed by Filter.
Just another question:
when a session is invalidated (manually, or by timeout)
javax.servlet.http.HttpSessionListener#sessionDestroyed(javax.servlet.http.HttpSessionEvent)
is always raised, is there some special case this method is avoided?
I maintain my own count of session and it never shows the same count as the tomcat manager...
Here is an idea of what I'm doing in my session listeners :
sessionDidActivate: cnt++ sessionCreated: cnt++
sessionDestroyed: cnt-- sessionWillPassivate: cnt--
Maybe I misunderstood something.
Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
