On this subject, PaulE wrote: > Seems to me that this is the simple question of 'global variables' or > 'passing parameters' style of coding. The 'global variables' > approach seems some what less object orientated in my opinion (Coming > from a 4GL background where I was haunted by global variables :-) )
I agree with you completely. The same sorts of design forces are involved with the Singleton pattern, as well -- and in many cases, the notion of a thread-scoped variable is as bad as any other form of global state. The fact that it's often a bad idea doesn't mean you shouldn't ever do it, though. Suppose that you've got a situation where your servlet needs to do some sort of setup work with a unit of work (or database connection; they're essentially the same for purposes of my point here), and then the servlet calls a method on helper A, which calls a method on helper B, which calls a method on helper C, and so on ... until ten levels deep in the call stack, helper J needs to do something to the Unit of Work. There are two things you can do here: 1) pass the unit of work as a parameter in essentially every call in the system that might conceivably result in a UOW call, even though it is almost never actually used; 2) make the unit of work available throughout the entire call tree by putting it in some sort of global location. I find option 1 to be a poor choice because the presence of the UOW as a parameter to all methods, when it is generally unused, does not clearly communicate the intention of the code. So in this case I am highly inclined to create a thread scoped variable (i.e., a ThreadLocal). Cheers, bn -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
