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>

Reply via email to