tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roggeveen, Brian P" <brian.roggev...@eds.com>
Subject RE: Threading Question
Date Fri, 01 Aug 2003 17:15:58 GMT
You are right about the Map. The ThreadLocal class is exactly what I am
looking for. Thanks for your help!

-----Original Message-----
From: Extance, Paul [mailto:paul.extance@spirent.com] 
Sent: Friday, August 01, 2003 10:40 AM
To: 'Tomcat Users List'
Subject: RE: Threading Question


We have had similar issues with wanting some objects to be accessible by any
classes executing in a thread that is processing the response. Our solution
was to use ThreadLocal to create a thread variable, if you are using either
a FrontController (like Struts) or a Filter that each request must pass
through, you can create the thread variable on entry, and unset it in the
'finally' block of your controller...

For an example of this here is...

a) a modified version of Struts controller that sets the variable via our
SecurityManager
http://jaffa.sourceforge.net/javadoc/1_2_0/src-html/org/jaffa/presentation/p
ortlet/PortletServlet.html#line.205

b) The class that actually manages the variable and uses it.
http://jaffa.sourceforge.net/javadoc/1_2_0/src-html/org/jaffa/security/Secur
ityManager.html#line.358

The core of this is simply...
364            // Attach the security context to the thread
365            bindToThread(ctx);
366            try {
367                // Now invoke the method
368                return method.invoke(obj, args);
369            } finally {
370                // As the last thing to do before returning either an
object or an exception
371                // Remove the current context from the thread
372                unbindFromThread();
373            }

If you want to use a filter, just replace the above 'return' with a
chain.doFilter( request, response ) inside your doFilter() method.

I think the concern with a static Map, it that it could give one thread
access to another threads data. I guess this is why things like
java.servlet.http.HttpSessionContext were deprecated in v2.2 because of
cross request access.

Paul Extance

-----Original Message-----
From: Bill Barker [mailto:wbarker@wilshire.com] 
Sent: Thursday, July 31, 2003 9:54 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: Threading Question


"Roggeveen, Brian P" <brian.roggeveen@eds.com> wrote in message
news:F85E99B28A65D411A6BC00508BE3242C143E8FD0@USPLM204.txpln.us.eds.com...
> Hello,
>
> I was wondering if it is safe to assume that when using the 
> multithreaded model, a single unique thread will handle each incoming 
> request? In other words, does the servlet container implement a thread 
> per connection model
or
> is there a way to specify this configuration?

The thread-per-connection model is mandated in the Servlet spec, so Tomcat
(and any other compliant Servlet-Container) will behave this way.

>
> The reason I ask is that at any given point within my servlets' 
> supporting code/beans, I would like to have access to the HttpSession 
> instance that corresponds to the client for whom the current line of 
> code is being executed. Another way of looking at the situation would 
> be at any given point within my servlets' supporting code/beans, I 
> would like to have
access
> to the HttpRequest that caused this particular line of code to be
executed.
> In order to accomplish this, I envisioned using a Map that contained
thread
> keys and HttpSession values. As requests came in, the Map would be 
> updated appropriately such that supporting code need only look up an 
> HttpSession using the current thread. Maybe I'm making this more 
> complex than it needs to be.

You are most definitely making this more complex than it needs to be ;-).

>
> Thanks!
> Brian Roggeveen
> EDS - Work Force Management
> Voice: (314) 264-8991
> Fax:    (314) 264-8901
> Email: brian.roggeveen@eds.com




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Mime
View raw message