• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

ojdbc6 vs tomcat-jdbc (or tomcat-dbcp)

 
Ranch Hand
Posts: 1067
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 20834
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
William Barnes
Ranch Hand
Posts: 1067
2
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!