Yes, the issue is that the ThreadLocal var *could* be the one set on the
previous request, therefore I have a filter that intercepts request to our
application, creates a WebTxCache:
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain)
throws IOException, ServletException
{
HttpServletRequest httpRequest = (HttpServletRequest) request;
/* == create cache == */
GenericWebTxCache cache = new GenericWebTxCache(httpRequest);
if (this.strategy != null)
{
cache.setStrategy(this.strategy);
}
Tx.bindCache(cache); <--- see code from last email
/* == continue on == */
chain.doFilter(request, response);
}
Since you are using an older version of Tomcat, you will not have access to
filters, but what you can do is extend the ActionServlet or RequestProcessor
from struts to do the same thing, since you would like to do the above
operation before it hits any of your Actions.
Jacob Hookom
Senior Analyst/Programmer
McKesson Medical-Surgical
Golden Valley, Minnesota
http://www.mckesson.com
-----Original Message-----
From: Pon Umapathy K.S. [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 8:42 AM
To: Struts Users Mailing List
Subject: RE: InheritableThreadLocal issues
Thanks for the reply,Jacob.
Just to confirm the issue -
This code snippet resets the object stored in the ThreadLocal var when a
set is made.Because there is a initial value specified,the ThreadLocal
object might be getting initialized to the GenericTxCache() object which
needed resetting.Did you check whether this was not the case?
In my case,the value in the ThreadLocal var is what was set using the same
thread by a previous request.
> -----Original Message-----
> From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 7:03 PM
> To: Struts Users Mailing List
> Subject: RE: InheritableThreadLocal issues
>
>
> I've been using ThreadLocal's and had to forceably reset the object on the
> ThreadLocal on every use to specify a transaction cache:
>
> public final class Tx
> {
> private static ThreadLocal localCache = new ThreadLocal()
> {
> protected synchronized Object initialValue()
> {
> return new GenericTxCache();
> }
> };
>
> /**
> *
> */
> private Tx()
> {
> super();
> }
>
> public static TxCache getCache()
> {
> return (TxCache) localCache.get();
> }
>
> public static void bindCache(TxCache cache)
> {
> ((TxCache) localCache.get()).reset();
> localCache.set(cache);
> }
> }
>
> -----Original Message-----
> From: Pon Umapathy K.S. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 7:27 AM
> To: Struts list
> Subject: InheritableThreadLocal issues
>
> Hi,
> A query regarding InheritableThreadLocal variables in the tomcat/struts
> context.
>
> To explain the problem i am facing:
> If i am correct,for each request,tomcat uses a thread from it's
> threadpool
> to process the request.
> Suppose during one of these requests,i set the value of a
> InheritableThreadLocal variable.Once this request is processed,the thread
> will be available for use from the ThreadPool.Does tomcat/struts reset the
> value of the InheritableThreadLocal variable which was set by the previous
> request processing?(it should,ideally). The tomcat version i am using is
> 3.3.1a.The struts version 1.0.
>
> It seems to me that the InheritableThreadLocal value which was set by a
> previous request on a thread is still retained when that thread is reused
> for processing another request.Are there any known issues regarding this?
> Would be really helpful if someone can answer this.A bit urgent.Thanks in
> advance.
>
> Regards,
> Umapathy
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
