On Thu, 31 Oct 2002, Brett Neumeier wrote:
> Date: Thu, 31 Oct 2002 13:04:59 -0600 > From: Brett Neumeier <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: JDBC / ThreadLocal pattern. > > > > 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? If you're using JNDI for data sources, you are actually retrieving the connection pool, not the connection. So, it won't address your issue of saving a connection in the session where needed (you can use the same technique you use now for that). Using the same connection or not is irrelevant for the cases where you don't try to maintain a transaction across web requests. > 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. As above, you get connection pools, not connections. You'd still need to save the allocated connection in the session and return it later for those scenarios, but that is not (and should not, for scalability reasons) be the common scenario. <separate-consideration-about-connection-in-session> There's one additional complexity to saving a Connection object in the session across web requests to think about, though -- what happens to you when there are multiple requests for the same session? This can happen more often than you might think. A couple of common causes: * Framed presentation, because the browser will often trigger multiple simultaneous requests, and they are all participating in the same session. * User submits a request that starts a long SQL query, presses STOP, and then submits a second request while the first one is still running. In any such scenario, it is not safe to assume that a Connection retrieved from a session is only being used by a single thread. You'll need to ensure that you don't try to retrieve it from more than one thread simultaneously. </separate-consideration-about-connection-in-session> > > Additionally: > > - you may not have a JNDI data source handy Tomcat provides one for you -- all you need is a JDBC driver. All J2EE app servers are required to provide one as well. > - you may not have JNDI configured JNDI itself is part of the container, it doesn't need to be "configured". The connection parameters for your data source have to be configured somewhere (either in your webapp's properties or the container's proeprties). The effort is going to be roughly the same. > - ThreadLocal is a fairly simple and light-weight thing to use You might find it amusing to examine how ThreadLocal is actually implemented -- basically, it's a Hashtable keyed by the Thread object, so calling get() and set() has the same performance impact as a get() or put() on a Hashtable. The JNDI context (in Tomcat for sure, most likely for others as well) is implemented as a glorified HashMap for each Context level, so retrieiving the data source has the same performance impact as a get() on a Hashtable. > > 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. That's definitely a benefit. However, JNDI provides you exactly the same benefit, so that by itself is not a useful criteria for choosing one approach versus the other. > > 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>
