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?
Please ignore post, I have no idea what I am talking about.
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.
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.