2 Cents... Not all threads need to do things with the database? kind of a waste to use the thread with the connection sitting idle, if it is a limited resource. I'm guessing the worker thread pool in tomcat typically needs to be higher that that of the connection pool its classes would use, in which case your hogging/wasting a valuable resource. This alone would probably justify not using it for me.
We sometimes using multiple connections in a single thread if our business process need two isolated transactions, one to do the work (which could rollback) and the other to do the logging to the database, which should not be rolled back with the main transaction. Could this be supported with a single connection per thread? If you have stateful form beans (say with STRUTS) that want to maintain connection state, can you guarantee that the same thread will service the same request associated to this stateful bean. I know in a web/stateless environment you probably don't want to leave connections open across successive calls...so maybe this is not a real issue.. PaulE -----Original Message----- From: Reynir Hübner [mailto:reynir@;hugsmidjan.is] Sent: Wednesday, October 30, 2002 11:06 AM To: Tomcat Users List Subject: JDBC / ThreadLocal pattern. Hi all, This email is a little bit off topic, as it's more about JDBC-related stuff than tomcat. I'm really looking for comments on the approach for JDBC connection pooling described in the article at : http://www-106.ibm.com/developerworks/java/library/j-threads3.html In (very) short: the idea here is to have one jdbc-connection for each thread, instead of a pool with connections. I've got few ideas on the subject, for example this may be cool because : 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.... I realise there must be some kind of problems by doing it this way, but I only came up with these : 1. can this approach cause too many connections to the database (75 threads in Tomcat is the default means 75 connections) ? 2. can it be to heavy for the garbagecollector to collect all the dead connections lying around when a thread dies ? 3. anything more negative stuff ? I am looking for comments on the pattern.. Please respons if you have any. Thanx alot! [EMAIL PROTECTED] -- 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>