Hibernate version: 3.0

Postresql 8.1.4

I am running Tomcat 5.5. Most of the time the web app runs fine but at times I get these exceptions sporadically. And the exceptions cannot be replicated the very next instance.

The code that throws these exceptions:



Where PdS() is a stored procedure residing in a Postgresql DB.

Any input will be helpful.

Thanks


org.hibernate.exception.GenericJDBCException: could not execute query
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2148)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
at org.hibernate.loader.Loader.list(Loader.java:2024)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:111)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1674)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:147)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:164)
at com.aa.bb.cc.cc.uPdS(Cc.java:150)
Caused by: java.sql.SQLException: Connection is closed.
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:174)
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:277)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
at org.hibernate.loader.Loader.doQuery(Loader.java:661)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2145)
... 36 more


And

org.hibernate.exception.GenericJDBCException: could not inspect JDBC autocommit mode
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:228)
at org.hibernate.impl.SessionImpl.afterOperation(SessionImpl.java:437)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1680)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:147)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:164)
at com.aa.bb.cc.cc.uPdS(Cc.java:150)
Caused by: java.sql.SQLException: Connection is closed.
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:174)
at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.getAutoCommit(PoolingDataSource.java:220)
at org.hibernate.jdbc.ConnectionManager.isAutoCommit(ConnectionManager.java:163)
at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:219)
... 34 more

This might not exactly answer your question but in general I have had weired experiences with Tomcat/DBCP mixes. Try to use another connection pool and see if that makes things better for you. In addition, many connection pools have an option that specifies a command, usually select 1, which can be used to see if a connection is still open. This command will be run each time a connection is being fetched from pool. Check if you have specified this option.



Farzad-

The properties for DBCP are validationQuery and testOnBorrow.



Farzad-

Thanks Farzad.

I am looking into your suggestion at this time. Will update the post with my findings.

Sudip

OK, it was because a session close statement was missing from the finally block and so whenever we had an exception, the session was not closed and and became reusable for an incoming transaction. Thus this session was at times available to 2 different threads leading to above inconsistent behavior.

Sudip