This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm not quite familiar with ThreadLocal class. What I need to do is pass a parameter to all methods in all service classes. So it become good candidate to use ThreadLocal to save this context info. However it is suggested in the office that ThreadLocal should be absolutely forbid in clustering j2EE application server environment due to the "clustering". Anyone have argument to support or against this statement?
"Clustering" refers to running an application on multiple machines for capacity purposes. J2EE has some elaborate mechanisms built in that allow objects to be transparently migrated from one machine to another in a cluster. Any dependence on the specific JVM in which an object lives -- such as using static variables, or ThreadLocals (which are effectively another kind of global variable) -- breaks these mechanisms. Don't do it.
Thank you Ernest very much for the reply. It's very helpful for my design.
Joined: Mar 16, 2005
I've been given a thought over weekend. And I'm still a bit confused. Since all the methods call in my application is invoked by one request from browser, therefore these methods invocation should live and die w/ the thread w/in the single JVM. This thread for servlet request will never propagate across the cluster. Why can't use threadLocal?
I'm not use ThreadLocal to save class level object, I just want it to keep the method context (not session context or anything else) so that my next method w/in same thread will get it. Therefore I don't have to pass this context to all my methods. Is is feasible?