I don't like this approach for connections in a web server. 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.
Even if the threads are recycled (If the servlet engine supports a ThreadPool and is configured to use it), you don't have control about which request gets which thread, so I don't see how you will use this to lazy load resultsets. In this case you also have no control when the threads are killed. (It's up to the servlet engine) If you don't need database access in every request (which is quite typical if you use tomcat standlone) the situation even gets worse. In the long term every thread in the pool will have a connection (Each time a request with database access that is assigned to a thread that has no connection a connection has to be created for that thread.) Many drivers have problems with connections that are not explicitly closed so you would have to make shure that close() is called whenever a thread is killed. It's also not a good idea to rely on the garbage collector to close connections as you don't have control when the gc is run. It's very likely that you keep much more connections open than you actually need, you might even run out of connections if you hit the database limit. With a connection pool you have a much better control about the amount of open connections. Ralph Einfeldt Uptime Internet Solution Center GmbH Hamburg, Germany Hosting, Content Management, Java Consulting http://www.uptime-isc.de > -----Original Message----- > From: Reynir Hübner [mailto:reynir@;hugsmidjan.is] > Sent: Wednesday, October 30, 2002 8:06 PM > To: Tomcat Users List > Subject: JDBC / ThreadLocal pattern. > > In (very) short: the idea here is to have one > jdbc-connection for each thread, instead of a pool with connections. > > 1. I will never have to worrie about not returning > connections anymore, as they will always be garbage collected > as soon as the thread is dead. > 2. The connection will be available for more than one > request so I can lazy load resultsets. > 3. This might make transaction-service implementation easyer > 4. many other great things.... > -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
