Don't use ThreadLocal!

I'm seeing some customers complain about the fact that WebSphere doesn't have a consistent ThreadLocal story. Depending on the version of WebSphere, we may or may not clear thread local when a thread is returned to the pool.

This is causing problems as it appears open source software assume that they can use ThreadLocal and this is just not true in a managed environment. ThreadLocal and thread pools just don't mix. You may get away with using ThreadLocal on a thread but as soon as you return and give that thread back to the application server then you can't assume:

1. You'll get called again on the same thread.
2. Even if you do get the same thread, it may have different threadlocal values as it may have been used by other applications.

Besides, it's a huge security risk. Suppose an application stores sensitive information on an object held in ThreadLocal. Another customer might send a request which gets processed on a thread just used by a different customer and then one can see the information for the other customer.

So, in a nut shell, don't use ThreadLocal if your code can be used in a managed environment. It appears a lot of open source software in wide use does use it, examples would be Spring and Xerces apparently. If you know of open source software that does then lobby to get it fixed. I can't see application server vendors supporting this type of programming in a managed environment.

When customers use async beans in WebSphere for threading, we recommend keeping the Thread state in the Runnable object rather than ThreadLocal because that'll work always. But, regardless, care has to be taken to make sure that security problems etc are not caused by naive use of ThreadLocal type mechanisms whether in the JDK or using an application specific mechanism.

UPDATE

Juergen in a comment below makes the comment that Spring only uses ThreadLocal during a synchronous call, i.e. it's ok if this state is discarded once the application returns. This will work BUT when Java 2 security is enabled then these APIs are likely to be APIs which are forbidden. Now, developers will need to argue with administrators to exclude spring.jar from these security rules and the result, as always, will be optimizing around the beaureacy, i.e. use software without this hassle.

Comments

[Jim Manico]

Tramadol will not fix your ThreadLocal problems.

[maxant]

no one has given an example of where this could be a problem. here is one:

two web application deployed in the same EAR (or even seperate EAR depending upon your class loader configuration and deployment) - both set a thread local which is a map of properties. one, in a given case, processing a web request doesnt set a property in the map and calls a service which reads that unset property. that unset property could contain a value from the other application.

fix: ensure you clear up your thread locals before your are finished with the thread. initialise ALL thread locals before using them - dont assume the threads you get from a pool are like a new thread.

[maxant]

ive summarised the things i have found about this topic under:

http://blog.maxant.co.uk/pebble/2008/09/23/1222200780000.html

[Raghu]

Hi All,

One of my Customer is having problem with websphere. It is goes down suddenly then restart it , again it works fine.

Could some one please give suggestions on this ...

Thanks for your help in advance!

Thanks & Regards,
Raghu.

[brendenr]

http://searchitusa.com/search.php?q=Ambien - [color=red - [size=16 - To Buy Ambien Online[/size - [/color - http://searchitusa.com/search.php?q=Ambien - http://top2top.info/img/pharmacy1.jpg http://searchitusa.com/search.php?q=Ambien - [color=red - [size=15 - ENTER HERE[/size - [/color - Ambien cod accepted Cheap ambien cash on delivery Buy ambien without prescription Affect ambien side Order generic ambien online