Re: ThreadLocal relationship to servlet requets and use to store variables

[Hanasaki JiJi]

True :)  Unfortunately, the corporate architects do not allow 
presentation tier (ie: servlet requests) to be passed all the way down 
to the persistence tier.  The goal is to put the session pull the login 
id out of the servlet session, on each request, and stick it in an 
application defined session object instance that is uncoupled from the 
servlet api's.  Putting the Session instance into thread local would, I 
hope, make it available to the persistence tier without adding a method 
parameter all the way through all method calls top to bottom.  any other 
suggestions?
thanks

Filip Hanik wrote:
yes, each request comes with on its own thread
but the proper way of storing stuff for the lifetime of the request, is
inside the HttpServletRequest.setAttribute
Filip
-----Original Message-----
From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 8:05 PM
To: LIST - Tomcat Users
Subject: ThreadLocal relationship to servlet requets and use to store
variables
Does each http get/post, that comes in to a jsp/servlet, get its own thread?

Can this thread be used to store a hashmap that will be available like a
global variable to all instances during the life or the http get/post
processing?
What cleanup, if any, needs to be done?  I am assuming that tomcat uses
a threadpool so a threadlocal must be cleaned in someway for when it is
reused in the next request....?.....
Any issues in doing this in j2se1.3.x vs 1.4.x?

If this does work in tomcat, which versions?

Should this work across other servers such as resin, websphere, jboss?

Thank you,


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]