#7 NullPointerException thrown from c3p0 driver

[Anonymous]

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 ]

[Steve Waldman]

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

[Nobody/Anonymous]

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

[Nobody/Anonymous]

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]

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]

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]

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]

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]

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.