This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Tomcat and the fly likes ojdbc6 vs tomcat-jdbc (or tomcat-dbcp) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Products » Tomcat
Bookmark "ojdbc6 vs tomcat-jdbc (or tomcat-dbcp)" Watch "ojdbc6 vs tomcat-jdbc (or tomcat-dbcp)" New topic
Author

ojdbc6 vs tomcat-jdbc (or tomcat-dbcp)

William Barnes
Ranch Hand

Joined: Mar 16, 2001
Posts: 986

Not sure if this should be posted in the JDBC forum.

Running tcServer (VMwares Tomcat) using ojdbc6.jar and am getting "maximum open cursors exceeded" error. Already tried cleaning up the code, but still have the problem. Googling says another possible solution is to use tomcat-jdbc.jar.

That is what confuses me. I don't see any driver class in tomcat-jdbc, and most of the information about this talks of connection pooling. Are these two jars covering different funcationlity? Is there any over lap? Am I not understanding a more basic some thing here?

Thanks.


Please ignore post, I have no idea what I am talking about.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16095
    
  21

The tomcat-jdbc.jar component appears to contain Tomcat 7's database connection pooling implementation. You didn't point to the Google answer that recommended it, but I'll be willing to give good odds that what it was was an overly-technical way of recommending the use of connection pooling instead of brute-force driver management.

General background info for any and all who might not be aware of it:

There is a certain amount of overhead involved in opening a database connection. Rather than go to all that work, a system that makes many frequent requests for database services should therefore consider using a connection pool, where a finite number of connections are already kept open waiting for use.

The connection pool mechanism does not actually return the Connection object itself. What it does is provide a façade object that mostly mirrors the functionality of the underlying Connection object (and implements the Connection interface). The primary difference between this façade and a raw Connection is that the façade object's close() method does not close the physical database linkage, it merely returns the object to the connection pool that it came from.

Connection pools work best when you obtain the connection, do as much work as quickly as possible as you can, and then close (release back to the pool). In J2EE, you should never attempt to hold a Connection object (pooled or not) between requests, since Connection is an Interface, not a persistent class, and so not only would you tie up the Connection far, far longer than needed, but any attempt to serialize it might fail.


Customer surveys are for companies who didn't pay proper attention to begin with.
William Barnes
Ranch Hand

Joined: Mar 16, 2001
Posts: 986

That helps. I was confused, thinking that tomcat-jdbc.jar was a replacement for ojdbc6.jar. So ojdbc6.jar contains the oracle db device drivers for java 6. While tomcat-jdbc.jar, and tomcat-dbcp.jar, contain the connection pooling code.
 
GeeCON Prague 2014
 
subject: ojdbc6 vs tomcat-jdbc (or tomcat-dbcp)