I use the same pattern to bind a security context to a thread, which is set/unset in a common controller for all Servlet request. So the theory of binding the stuff to a thread works well, even in an EJB context, as they are single threaded too.
So the theory is good, but if you going to have a connection pool anyhow, this is just a lazy way to pass the connection around. Still seems like overkill if many calls don't need to use the database for anything... I guess you could be lazy and only get the connection from the pool and bind it to the threadlocal just before you use it for the first time. You'd still need to go straight to the connection pool, if you needed to use a second connection in the same thread. We use a pattern similar to the Fowler UOW pattern (Unit Of Work) and pass that around where needed 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 :-) ) PaulE. -----Original Message----- From: Brett Neumeier [mailto:brett.neumeier@;ualloyalty.com] Sent: Thursday, October 31, 2002 9:19 AM To: 'Tomcat Users List' Subject: RE: JDBC / ThreadLocal pattern. > > If the connection is available for more than one request > > depends on the way the container handles threads. If each > > request is a new Thread you will win nothing. > > Instead you will loose performace as each request > > would create a new connection to the database. > > Yes that is true, there for we've thought of a way to have > the ThreadLocal get its connection from a pool. The notion of binding a Connection to a particular Thread using a ThreadLocal is a pretty good idea. 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: - At the beginning of your processing, check out a Connection from a connection pool and bind it to the ThreadLocal. - Throughout processing, the ThreadLocal can be used to obtain access to the Connection. - At the end of your processing, close the connection (which returns it to the connection pool) and reset the ThreadLocal. If you need to maintain database state across multiple HTTP requests, a slight modification is needed: before you check a Connection out from the connection pool, look in the HttpSession to see whether there is a Connection there already. If there is, bind that Connection to the ThreadLocal. Otherwise, obtain a new Connection and put it both in the HttpSession and in the ThreadLocal. In the context of servlets, one good way to structure this would be to create a ServletWithConnection class (extending HttpServlet), and have its service() method look something like this: protected static ThreadLocal tl = new ThreadLocal(); protected void service (......) { Connection conn = connPool.getConnection(); tl.set(conn); super.service(); tl.set(null); conn.close(); } Then you can extend this servlet whenever you need a database connection, override doGet, doPost, whatever, as normal, and access the Connection via tl.get() whenever you need it. Incidentally, Martin Fowler talks about this in his new book on enterprise architecture patterns -- look at the "registry" pattern. http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0321127420 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> -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
