Adam,
Another option which might be better/easier/less intrusive (or very
similar) is to create an single place for storing thread local
variables. Like an OFBizThreadLocal class, which extends ThreadLocal.
Keep all the variables inside this class, then just tie in
ContextFilter (after the final chain.doFilter() call) and in the
JobInvoker class calls to OFBizThreadLocal.clear().
What do you think about that?
Andrew
On May 1, 2009, at 3:00 PM, [email protected] wrote:
Yeah I'm game for a more definite fix. But what about app server
threads?
Andrew
On May 1, 2009, at 2:42 PM, Adam Heath <[email protected]> wrote:
[email protected] wrote:
Author: jaz
Date: Fri May 1 17:47:52 2009
New Revision: 770771
URL: http://svn.apache.org/viewvc?rev=770771&view=rev
Log:
Often thread pools do not clear ThreadLocal, implemented a
workaround to handle this
Actually, never, until the Thread is shutdown. ThreadLocal is just
for storing stuff against a thread-type key. What you want is a
PoolThreadLocal, which doesn't exist.
I guess I could add code to support the same thing that webslinger
does for this case. It would require modifying ControlServlet,
JobPoller, and any other pool-like container class, to add a hook to
run an AtExit list of hooks. Then, add a utility class that allows
for singleton per-thread calls, and at-exit calls when the pool
returns the thread for further processing.
If this sounds confusing, it's that it's difficult for me to explain,
and would just be easier if I add the feature(or otherwise show the
code).
