As a general rule, you don't need to connection pool yourself. It is usually suggested (in the JDBC docs, for example) that you NOT pool, because it is the responsibility of the drivers themselves to pool. For instance, I think the HSQL driver pools automatically, and I can't imagine that Sybase or Oracle drivers don't automatically pool underneath you.
Basically, it's not the app developer's responsibility to do this, so don't bother unless you know for sure that the driver doesn't do it for you.
-Tyler
On Mar 23, 2004, at 3:41 PM, John Glorioso wrote:
I have a general question about James' jdbc connectivity. How efficient is it? What I mean is does it employ connection pooling? I was looking through the code and it seemed to suggest that it is done in the avalon framework, but reading the docs in config.xml, I began to second guess it. Just to clarify that I my idea of pooling is clear, let me explain some. Typically in a high volume web application, one would create a database pool of n connections that are opened when the application is started and kept open for queries. Built in functionality expires these connections, grows the pool, and shrinks it as necessary. After leaving weblogic many years ago, I have implemented my own Connection pooling library that does this similarly and had planned on using it as a wrapper to the mysql driver for James, but my question is do I need to do this? Does Avalon or James already do this?
What leads me to really be thinking about this is the JDBCVirtualUserTable class (yeah, I know enough with the virtual hosting stuff). If this class is constantly querying the James database it is going to put significant additional load if it is constantly opening and closing connections.
Bottom line. Should I use my connection pooling or is it redundant?
--------------------------------------------------------------------- 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]
