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