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:[EMAIL PROTECTED] 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:[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
