> > The notion of binding a Connection to a particular Thread using a > > ThreadLocal is a pretty good idea. > I do not agree.
Well, OK. > > The big advantage to my mind is that you > > can use the Connection from any level of the call tree > without passing it > > around as a parameter. What you need to keep in mind is > that you must reset > > the ThreadLocal before the Thread leaves your control. In > other words: > > > > You get exactly the same benefit (not having to pass the connection > around) if you use a data source accessed via JNDI. All the > rest of the > ThreadLocal manipulation is needless complexity. Do data sources accessed via JNDI guarantee that they return the same connection to your service thread on each invocation? I am ignorant of how JNDI works, but I would have thought that if you merely access your data source via JNDI all you can do is obtain some connection or other at any given time -- rather than the Connection that contains the particular transaction that your particular session is using. Or do you mean, once you obtain a Connection, you make it accessible via JNDI as a named resource? It seems to me that that's going to involve a /lot/ more overhead than just using a ThreadLocal. Additionally: - you may not have a JNDI data source handy - you may not have JNDI configured - ThreadLocal is a fairly simple and light-weight thing to use Again, the main benefit of using a ThreadLocal to store a reference to the connection is that objects operating at very different levels of the call tree can use the same connection without passing it around as a parameter all over. 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>
