• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

org.apache.tomcat.dbcp.dbcp.AbandonedTrace$AbandonedObjectException. Leak using connection pool

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,

I'm not sure, if this is the right forum to ask a question on connection leak, or JDBC forum. But since the exception is coming from tomcat dbcp, thought of starting from here. Lately, we are observing the AbandonedObjectException in our prod environment for few programs. We are using ojdbc6.jar and tomcat-dbcp from 6.0 version.

In most of the cases, where see this exception is when oracle.sql.ARRAY is created and used. We have a utility method which creates ARRAY object and returns to the calling functions to be used in passing as IN parameter to stored procedures. The psuedo code looks like below



We use this returned object and call the stored procedures with in another try/catch block with a new connection object and that object is also closed in finally block. I could not understand what and where the leak would have been possible and the connection object was abondoned.

There is one possibility I see here, in the creation of ARRAY, I see Connection is set to arrayDescriptor like "arraydescriptor.setConnection(connection);" I do not know, how this arrayDescriptor is later used during the stored procedure call, to which this ARRAY is passed IN. But as per the above code, the connection is closed, before returning back the ARRAY object. So, again I could not understand what is the impact on the connection that is set to ArrayDescriptor. But since there was no issue in making DB call and the values being returned properly, I believe what is being done here is correct.

Any pointers, what could have gone wrong with respect to the connection leak.
 
Scandha Ravi
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Additional information

We are getting the connection object as


Could this be a reason?
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, quite likely you are correct. At any rate you should certainly be closing the Connection object which is returned by dataSource.getConnection().
 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When using a Connection Pool, the actual Connection returned from the pool isn't a raw JDBC Connection, it's a façade Connection. In your case: org.apache.tomcat.dbcp.dbcp.DelegatingConnection.

It is essential that you close this Connection after use. The reason for the delegating Connection is that its close() method doesn't close the database link like the close() method would on the actual underlying connection, but it does return that Connection to the Pool (with the underlying Connection still open so that when it's next used the system doesn't have to open a new one). That, in fact, is the reason for the façade - to alter the behavior of the close() method and make it more pool-friendly.

There is an "orphan Connection" property that you can set on the Tomcat database connection pool that will cause a stack trace to be logged when a Connection isn't properly closed. You can use this feature to detect offending points in the application.

If connections are not managed properly, eventually the application will starve for connections and malfunction. This is the reason why I recommend that application components should obtain and release connections within their own components rather than simply obtaining connections and passing them out for external usage (and hoping that the external users remember to close them).
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic