On Thu, 31 Oct 2002, Brett Neumeier wrote:
> Date: Thu, 31 Oct 2002 12:45:48 -0600 > From: Brett Neumeier <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: JDBC / ThreadLocal pattern. > > 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). > Don't forget that JNDI resources implement option 2 for you (the InitialContext object you get is essentially a per-webapp global), with no extra work required. They have the additional advantage that the containe supports external configuration of the resources, so you generally don't have to program that kind of thing either. > Cheers, > > bn Craig -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
