net.bull.javamelody.JdbcDriver does not work with c3p0 statement cache

[GoogleCodeExporter]

What steps will reproduce the problem?
1. In hibernate set net.bull.javamelody.JdbcDriver as driver_class and 
com.mysql.jdbc.Driver as driver
2. set c3p0.max_statements to something higher than 0
3. start making so calls to db

What is the expected output? What do you see instead?
I would expect no runtime exceptions, but instead when I reach the 
max_statements limit starts producing the following: 

Caused by: java.lang.RuntimeException: Internal inconsistency: A (not new) 
checking-out statement is not in deathmarch.
    at com.mchange.v2.c3p0.stmt.GooGooStatementCache$Deathmarch.undeathmarchStatement(GooGooStatementCache.java:676)
    at com.mchange.v2.c3p0.stmt.GlobalMaxOnlyStatementCache.removeStatementFromDeathmarches(GlobalMaxOnlyStatementCache.java:50)
    at com.mchange.v2.c3p0.stmt.GooGooStatementCache.checkoutStatement(GooGooStatementCache.java:188)
    at com.mchange.v2.c3p0.impl.NewPooledConnection.checkoutStatement(NewPooledConnection.java:234)
    at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:199)

This problem only occurs when using the javamelody wrapper.

What version of the product are you using? On what application server, JDK,
operating system?
javamelody 1.44, c3p0 0.9.2.1, mysql driver 5.1.24, Tomcat, Linux

Please provide any additional information below.

Original issue reported on code.google.com by vahlst...@gmail.com on 8 May 2013 at 1:54

[GoogleCodeExporter]

Can you give the simplest code to reproduce the problem?

Original comment by evernat@free.fr on 8 May 2013 at 2:09

[GoogleCodeExporter]

Hi there,
Thanks for quick response.

We have actually decided in the mean time two abandon c3p0 and use Tomcat
connection pool instead - and only use caching of preparedstatements in
MySQL not in the pool. We will of cause keep using javamelody :)

Sorry for the inconvenience. If you still are interested in tracking down
the possible bug here are some pointers:

The place i goes wrong is in com.mchange.v2.c3p0.stmt.GooGooStatementCache
in c3p0 v0.9.2.1
in the following method starting at line: 704:

It seems that registered statements doesn't match the statements which
should be unregistered when the maxStatements limit is met in c3p0. Are
there an inconsistency in a hashCode or equals method? The statements seems
to be stored in a Map-implementation.

        public void undeathmarchStatement( Object ps )
        {
            assert Thread.holdsLock(GooGooStatementCache.this);

            Long old = (Long) stmtsToLongs.remove( ps );
            if (Debug.DEBUG && old == null)
                throw new RuntimeException("Internal inconsistency: " +
                "A (not new) checking-out statement is not in deathmarch.");
            Object check = longsToStmts.remove( old );
            if (Debug.DEBUG && old == null)
                throw new RuntimeException("Internal inconsistency: " +
                "A (not new) checking-out statement is not in deathmarch.");
        }

Original comment by vahlst...@gmail.com on 8 May 2013 at 8:41

[GoogleCodeExporter]

The equals and hashCode methods are currently delegated from the javamelody 
proxy to the underlying statement (that is some c3p0 statement or some jdbc 
driver statement).
So it may depend also on what is exactly the source code of c3p0.

We may do otherwise than just delegate (such as unwrap the statement proxies 
"this" and the parameter before equals), and check perf afterward.
But we are currently not that much interested in c3p0 v0.9.2.1 at the moment.

So closing as won't fix for now, if it's not a problem for you anymore.

Original comment by evernat@free.fr on 8 May 2013 at 10:09

• Changed state: WontFix

[GoogleCodeExporter]

Thats fine :)
Thanks for replying
Den 09/05/2013 00.09 skrev <javamelody@googlecode.com>:

Original comment by vahlst...@gmail.com on 8 May 2013 at 10:13