You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Causse <dc...@cognitis.fr> on 2005/03/10 20:47:25 UTC
Access Threads informations/state
Hi,
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).
When the user hit the "Home" link I have to clean all the session
attributes, but I don't want to clean the Connections if they are in use.
In normal condition and in a perfect world no Connection should be
present in the session when home is called, but it is a very big app...
The session attribute name is like
"Connection"+Thread.currentThread().getName().
So when hitting home I loop over all attributes in the session and I do
special case for each type of class I find. So when I find a Connection
object I first have to close() before gc.
I know wich Thread generated this Connection (I can easely extract the
Thread name) and I would like to close it *only if I'm sure that this
Thread is not serving something*.
This case should happen because there is some big db extraction that the
user can open inside a sort of popup and continue working on the main
app screen waiting for the export to finish.
I identified 3 solutions to solve my problem :
- Do not close a java.sql.Connection if there is still open Statement on
it - I don't know how to do.
- Ask tomcat if the thread is serving a request - I don't know how to do.
- Never close Connection - I don't like this one...
We use :
- JAVA 1.4
- Tomcat 5
- Oracle 9i with jdbc thin driver with our own connection pool management.
Thank you for you help.
David.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Access Threads informations/state
Posted by David Causse <dc...@cognitis.fr>.
QM wrote:
>On Thu, Mar 10, 2005 at 08:47:25PM +0100, David Causse wrote:
>: 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.
>
>
I hope my boss didn't heard you :)
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Access Threads informations/state
Posted by QM <qm...@brandxdev.net>.
On Thu, Mar 10, 2005 at 08:47:25PM +0100, David Causse wrote:
: 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.
: When the user hit the "Home" link I have to clean all the session
: attributes, but I don't want to clean the Connections if they are in use.
: In normal condition and in a perfect world no Connection should be
: present in the session when home is called, but it is a very big app...
: The session attribute name is like
: "Connection"+Thread.currentThread().getName().
The problem you may run into, long-term, is that a Java webapp isn't
supposed to rely on container-specific features, especially something as
low-level as the thread model.
I don't see a quick solution to this. Just about anything you find
right now will be a short-term holdover, and will eventually bite you
down the line. If at all possible, consider refactoring the data access
of your app such that this isn't an issue.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org