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
365bindToThread(ctx);
366try {
367// Now invoke the method
368return 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
372unbindFromThread();
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]
RE: Threading Question
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
365bindToThread(ctx);
366try {
367// Now invoke the method
368return 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
372unbindFromThread();
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]
RE: Threading Question
You could do something like that, or you could just have the servlet pass that into the supporting code/beans. It'd be a lot cleaner and clearer design wise to just pass the information, either encapsulated into a new object or just the values you need. --mikej -=-- mike jackson [EMAIL PROTECTED] -Original Message- From: Roggeveen, Brian P [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 3:53 PM To: '[EMAIL PROTECTED]' Subject: Threading Question 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 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. 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]
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]
