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:[EMAIL PROTECTED] 
Sent: Thursday, July 31, 2003 9:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Threading Question


"Roggeveen, Brian P" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]




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

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

Reply via email to