#7 NullPointerException thrown from c3p0 driver

v1.0 (example)
closed
None
5
2014-10-05
2005-03-16
Anonymous
No

This problem happened at c3p0 0.8.5 and later(it didn't
happen at 0.8.4.5), with JDBC driver 7.4 and 8.0.

Sometimes after the connection pool was running for a
while or after a constraint violation happened, a
NullPointerException was thrown when using the c3p0
connection pool.

Here is a sample stack trace:

Mar 15, 2005 5:46:11 PM
net.sf.hibernate.util.JDBCExceptionReporter logExceptions
WARNING: SQL Error: 0, SQLState: null
Mar 15, 2005 5:46:11 PM
net.sf.hibernate.util.JDBCExceptionReporter logExceptions
SEVERE: You can't operate on a closed connection!!!
Mar 15, 2005 5:46:11 PM
net.sf.hibernate.util.JDBCExceptionReporter logExceptions
FINE: Could not execute JDBC batch update
java.sql.SQLException: You can't operate on a closed
connection!!!
at
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:68)
at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.close(NewProxyPreparedStatement.java:1682)
at
net.sf.hibernate.impl.BatcherImpl.closePreparedStatement(BatcherImpl.java:273)
at
net.sf.hibernate.impl.BatcherImpl.closeStatement(BatcherImpl.java:141)
at
net.sf.hibernate.impl.BatcherImpl.executeBatch(BatcherImpl.java:130)
at
net.sf.hibernate.impl.BatcherImpl.prepareStatement(BatcherImpl.java:60)
at
net.sf.hibernate.impl.BatcherImpl.prepareStatement(BatcherImpl.java:57)
at
net.sf.hibernate.impl.BatcherImpl.prepareBatchStatement(BatcherImpl.java:110)
at
net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:637)
at
net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:623)
at
net.sf.hibernate.impl.ScheduledUpdate.execute(ScheduledUpdate.java:52)
at
net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2438)
at
net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2392)
at
net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2260)
at
net.sf.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:61)
at
com.sun.hss.domain.internal.HibernatePersistenceToolkit.store(HibernatePersistenceToolkit.java:105)
...
Caused by: java.lang.NullPointerException
at
org.postgresql.jdbc1.AbstractJdbc1Statement.getResultSet(AbstractJdbc1Statement.java:771)
at
org.postgresql.jdbc1.AbstractJdbc1Statement.close(AbstractJdbc1Statement.java:795)
at
com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.close(NewProxyPreparedStatement.java:1674)
... 41 more

Here are the c3p0 configuration dump:
Initializing c3p0 pool...
com.mchange.v2.c3p0.PoolBackedDataSource@c4fe76 [
connectionPoolDataSource ->
com.mchange.v2.c3p0.WrapperConnectionPoolDataSource@b23210
[ acquireIncrement -> 1, acquireRetryAttempts -> 30,
acquireRetryDelay -> 1000, autoCommitOnClose -> false,
automaticTestTable -> null, breakAfterAcquireFailure ->
false, checkoutTimeout -> 0, connectionTesterClassName
-> com.mchange.v2.c3p0.impl.DefaultConnectionTester,
factoryClassLocation -> null,
forceIgnoreUnresolvedTransactions -> false,
idleConnectionTestPeriod -> 3000, initialPoolSize -> 0,
maxIdleTime -> 5000, maxPoolSize -> 2, maxStatements ->
100, maxStatementsPerConnection -> 0, minPoolSize -> 0,
nestedDataSource ->
com.mchange.v2.c3p0.DriverManagerDataSource@19360e2 [
description -> null, driverClass -> null,
factoryClassLocation -> null, jdbcUrl ->
jdbc:postgresql://localhost:5433/rox, properties ->
{user=******, password=******} ] , preferredTestQuery
-> null, propertyCycle -> 300, testConnectionOnCheckin
-> false, testConnectionOnCheckout -> false,
usesTraditionalReflectiveProxies -> false ] ,
factoryClassLocation -> null, numHelperThreads -> 3,
poolOwnerIdentityToken -> c4fe76 ]

Discussion

  • Steve Waldman
    Steve Waldman
    2005-03-24

    Logged In: YES
    user_id=175530

    Hi.

    I think that this may have been caused by the very bad bug
    in c3p0-0.8.5, c3p0-0.8.5.1, and c3p0-0.9.0-pre2 wherein
    cached PreparedStatements were being erroneously closed
    while in the cache. Please retest with c3p0-0.8.5.2, which
    fixes that problem, and see if the error still occurs.

    Thanks!

    Steve

     
  • Steve Waldman
    Steve Waldman
    2005-03-24

    • assigned_to: nobody --> swaldman
    • status: open --> closed
     
  • Logged In: NO

    I think this bug still exists in 0.8.5.2.

    Caused by: java.lang.NullPointerException
    at
    com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:173)
    ... 71 more

     
  • Logged In: NO

    And

    at
    com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:68)
    at
    com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:198)
    at
    net.sf.hibernate.impl.BatcherImpl.getPreparedStatement(BatcherImpl.java:263)
    at
    net.sf.hibernate.impl.BatcherImpl.getPreparedStatement(BatcherImpl.java:236)
    at
    net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:67)
    at
    net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:784)
    at
    net.sf.hibernate.loader.Loader.doQuery(Loader.java:269)
    at
    net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:138)
    at
    net.sf.hibernate.loader.Loader.doList(Loader.java:1063)
    at net.sf.hibernate.loader.Loader.list(Loader.java:1048)
    at
    net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:854)
    at
    net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1554)
    at
    net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:49)

     
  • Steve Waldman
    Steve Waldman
    2005-04-07

    Logged In: YES
    user_id=175530

    nobody,

    Can you please post the full stack trace, including the
    message line at the top, all the way through the "cause by"
    Exception?

    Is the message "You can't operate on a closed
    connection!!!"? If so, please be sure that you haven't
    inadvertantly called close() on the Connection prior to your
    call to prepareStatement().

    I think that this is a different issue than the one
    described above. That involved NullPointerExceptions
    occurring within PreparedStatement methods, rather than in
    the prepareStatement(...) method of a Connection. (I do
    think that has been fixed.) But it does look like an issue
    reported by mxnmatch on the hibernate forums, which followed
    constraint violation exception. Did your Exception follow
    some provoking initial exception?

    Also, please download the latest prerelease of c3p0-0.9.0
    (-pre4), and give it a try. When you report the issue,
    please include the banner (which will include the version
    and build time) and the config dump, as well as the
    complete Exceptions.

    Thanks!

    Steve

     
  • subbu
    subbu
    2014-09-30

    Hi Steve Waldman,

    I am using c3p0-0.9.2 and and still getting the issue of Null pointer exception...
    SQL Error: 0, SQLState: null
    2014-09-29 12:11:37,175 [TP-Processor3] ERROR [hibernate.util.JDBCExceptionReporter] - You can't operate on a closed ResultSet!!!
    ...
    ...
    Caused by: java.lang.NullPointerException
    at com.mysql.jdbc.ResultSetImpl.checkColumnBounds(ResultSetImpl.java:817)
    at com.mysql.jdbc.ResultSetImpl.getLong(ResultSetImpl.java:2922)
    at com.mysql.jdbc.ResultSetImpl.getLong(ResultSetImpl.java:2911)

    Could you please let me know in which release it is fixed, which version to use?

    Thanks in Advance,

    Regards
    Subbu

     
  • Steve Waldman
    Steve Waldman
    2014-09-30

    Hi. The Exception you are catching is not a NullPointerException, but an SQLException, whose message is "You can't operate on a closed ResultSet!!!". That's the problem you have to deal with.

    The "caused-by" Exception is an NPE, which is caught and rethrown as the SQLException. That's just how c3p0 internally detects that you are operating on a closed proxy. But your application never sees or catches the NPE. It has already been caught and wrapped.

    There's no c3p0 issue here. You have to figure out why you are operating on ResultSets which have already been closed, either because your application close()ed them directly, or because the Statements or Connections from which they were derived have been close()ed.

     
  • subbu
    subbu
    2014-10-01

    Hi Steve,

    Thanks for the response and helping me to understand.

    We do not use any Result set, we are using Spring with JPA and c3p0. we do not manage any connections manually, have few named queries which are actually throwing exceptions. They are also not consistent, some time they work fine and sometime they do not.

    I have few more other logs which points me the same exceptions. Please refer the stack trace below..

    Thanks
    Subbu

    Stack trace:

    2014-09-29 15:18:19,593 [TP-Processor3] INFO [c3p0.stmt.GooGooStatementCache] - Multiply prepared statement! select workitemin0_.workItemId as workItemId7585_0_, workitemin0_.creationDate as creation2_7585_0_, workitemin0_.externalVariables as external3_7585_0_, workitemin0_.name as name7585_0_, workitemin0_.processInstanceId as processI5_7585_0_, workitemin0_.state as state7585_0_, workitemin0_.OPTLOCK as OPTLOCK7585_0_, workitemin0_.workItemByteArray as workItem8_7585_0_ from WorkItemInfo workitemin0_ where workitemin0_.workItemId=?
    2014-09-29 15:18:19,602 [TP-Processor3] WARN [hibernate.util.JDBCExceptionReporter] - SQL Error: 0, SQLState: null
    2014-09-29 15:18:19,602 [TP-Processor3] ERROR [hibernate.util.JDBCExceptionReporter] - You can't operate on a closed Statement!!!
    2014-09-29 15:18:19,606 [TP-Processor8] INFO [hibernate.type.StringType] - could not read column value from result set: formula4_1_; Operation not allowed after ResultSet closed
    2014-09-29 15:18:19,612 [TP-Processor8] WARN [hibernate.util.JDBCExceptionReporter] - SQL Error: 0, SQLState: S1000
    2014-09-29 15:18:19,612 [TP-Processor8] ERROR [hibernate.util.JDBCExceptionReporter] - Operation not allowed after ResultSet closed

     
  • Steve Waldman
    Steve Waldman
    2014-10-05

    Hi,

    It's very likely that you are letting multiple Threads work with your Statements and ResultSets. This is almost always a bad idea. One way or another, all of these "You can't operate on a closed XXX" warnings mean that some Thread is still working with a Statement or ResultSet after another Thread (or it itself) has already close()ed it.

    To debug this, you'll want to capture the full stack traces, not just the messages, in your logs (c3p0 does log the stack traces), to see where in your code you are working with Statements and ResultSets that might already have been closed.

    The "Multiply prepared statement!" message suggests that perhaps you have multiple Threads sharing at the Connection level. It means that from the same Connection, the same PreparedStatement has been requested twice, which you could conceivably do on purpose in a single thread, but probably means you are unadvisedly sharing the Connection between multiple threads who are using the same code to prepare the same Statement.

    You'll want to ensure that you are properly restricting use of Connections, Statements, and ResultSets, from the moment of checkout to the moment of close, to use by a single Thread.