Pooling still makes sense although in modern servlet containers it's
provided. Outside the JVM, there's the overhead of making the
connection and authenticating that can eat up significant amounts of
time in busy sites with large numbers of queries to the db. Those costs
are completely outside the JVM and would occur in stuff built with any
of the other languages.
Overall, do some performance testing on your webapp. If it's need of a
database is so low that connections timeout and get recycled between
borrows from the pool, you probably could get away with out the pooling.
--David
Jonathan Mast wrote:
I'm developing a webapp that is going to be making frequent DB operations.
I know that DB connections are expensive and that developers pool
connections to prevent the overhead of frequent instantiation. Is this
design pattern still necessary? I ask because I vaguely recall skimming
over an article that stated that this design pattern is not needed anymore
with newer versions of Java.
Currently, our webapps make infrequent calls to our database and as such I
simply use a static getConnection() method to create new Connections, which
I explicitly close at the end of their use.
I realize that our setup, Tomcat 5.5 on Java 1.4.2, will almost certainly
require connection pooling. But does newer versions of Java obviate this
need?
Any pointers to relevant (ie. JDK 1.4.2) tutorials on this topic would be
greatly appreciated.
Thanks
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
