Hello, Filip. I know that performance is the primary reason for using connection pooling, but whether or not to use connection pooling was not my question. I wanted to know whether or not Tomcat 4.x has connection pooling built-in, and what difference it would make in letting Tomcat 4.x use its internal connection pooling versus explicitly declaring DBCP to be a datasource factory.
But after having read your message, you are suggesting that Tomcat 4.x does indeed have connection pooling built-in. Correct? If that is true, then I believe that I can safely assume that it uses Jakarta Commons DBCP to provide this connection pooling. Correct? That, in turn, would lead me to conclude that specifying DBCP to be the "factory" of a JNDI-deployed JDBC datasource is redundant since Tomcat is going to use DBCP anyway. Correct? So, there would be nothing gained by explicitly declaring DBCP to be your datasource factory since Tomcat will be using it anyway. If the foregoing assumptions are all correct, then my question has been answered. Here are a couple more questions that I have about the built-in connection pooling provided by Tomcat 4.x. 1) Does Tomcat always use DBCP if no datasource factory parameter is specified? Or does it have a means to discover the datasource factory provided by the JDBC driver that you specify? That is, does the JDBC 2.0 specification provide a means for Tomcat to discover that it can/should use com.mysql.jdbc.jdbc2.optional.whatever as a datasource factory for MySQL connections, for example? 2) What are typical considerations for choosing to use DBCP over a vendor's native datasource factory? That is, what are typical reasons for choosing to use com.mysql.jdbc.jdbc2.optional.whatever over org.apache.commons.dbcp.whatever? For example, is the memory footprint of one implementation versus the other a factor? What types of features do vendors provide (or not provide) that would lead an application developer to choose one datasource factory over the other? Has any one of the DBCP or vendor implementations had a history of being problematic in some way? Thread unsafe? Maturity? Feature set? Performance? Support? -----Original Message----- From: Filip Hanik [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 17:52 To: Tomcat Users List Subject: RE: Tomcat 4.x Provides Connection Pools for JDBC Datasources Automatically? the obvious gain from using a pool vs a non pooled connection is performance. but whether you use the tomcat DBCP or your own, doesn't really matter. Filip -----Original Message----- From: Sean Dockery [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Tomcat 4.x Provides Connection Pools for JDBC Datasources Automatically? I recently picked up a copy of Mastering Tomcat Development (0471237647). The following is an excerpt from the book's chapter entitled Databases, Connection Pools, and JDBC: "Prior to Tomcat 4, there was no connection pooling functionality within Tomcat, and you had to make a choice about the connection pooling technology to use. With Tomcat 4.x, you get an easy-to-use connection pooling library to work with, built into the server." The book then provides examples of a Resource declaration for each of Tomcat 4.0.x and Tomcat 4.1.x (using driverName versus using url as the parameter name). Is what the authors claim true? If so, what do I gain by using a connection pooling layer such as DBCP? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
