On Thu, 31 Oct 2002, Brett Neumeier wrote:
> Date: Thu, 31 Oct 2002 11:18:54 -0600
> From: Brett Neumeier <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> 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.
I do not agree.
> 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.
> - 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 you're going to keep a Connection in the session (across requests) at
all, you're wasting your time bothering with a connection pool -- you've
already said you're willing to leave an expensive resource (an open
connection to the database) allocated to a particular user in between
requests, even if the user went to lunch. You might as well just open a
connection when the session is created, and close it when the session
completes.
Also, if you plan on leaving a database transaction open across web
requests, you should really start your design over. There is no way to
make an architecture like that scale up to large numbers of users, because
you end up needing a database connection (and an active transaction) per
concurrent *user* of your application (i.e. everyone who is logged on and
has an active session) instead of a database connection per current
*request*.
Why should the database connection I just used remain unavailable to other
users while I'm looking at the previously generated response page? Why
should other users have to wait to access rows that I'm in the middle of
updating, and my transaction has locked?
> 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.
>
This pattern doesn't violate the principles I've described above (because
it gives the connection back before the request is completed), but it
does do unnecessary work if you're running on a servlet container that
provides data sources via JNDI resources -- and that means every J2EE app
server in the world, plus Tomcat 4.x and 5.x, and I'm sure a bunch of
others.
> 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
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
