What is the cause of this error java.lang.IllegalStateException: Trying to return an unknown connection2?

Question

I bump into this kind of error while running my apps. It happens occasionally so i dont know what exactly in my code this error originates. The exception does not tell any clear details.

A piece of the stacktrace.

java.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6@c74ff1
    at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:330)
    at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.connectionClosed(TxConnectionManager.java:720)
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:362)
    at org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection.java:155)
    at org.hibernate.connection.DatasourceConnectionProvider.closeConnection(DatasourceConnectionProvider.java:97)

Is there anybody who encounetered this error before please help. Im using jboss 6, seam 2, jsf 2 and richfaces 3.

Answer 1

This is answered in the JBoss wiki. Here's a cite of relevance:

Many persistence frameworks (Hibernate2/OBJ) open and close connections "at random". As far as JBoss is concerned it looks like one ejb allocated the connection and another closed it. The connection close checking does not understand this behaviour. It expects the same ejb that allocated the connection to also close it.

If you use such a pattern or such a framework, you can turn off this message (see below) but you are on your own when it comes to detecting connection leaks. From 3.2.6 there is a "listInUseConnections()" on the CachedConnectionManager.

However, there is this known issue with some transaction demarcation semantics. This is not really a JBoss use, more that ThreadLocal patterns bypass J2EE semantics.

If you do hit the problem, removing the CachedConnectionInterceptor from the interceptor stack in conf/standardjboss.xml will workaround the spurious message. In particular with Hibernate2, this is safe as you can trust hibernate at least to close connections properly provided you end user transactions correctly.

To remove the CachedConnectionInterceptor, edit the conf/standardjboss.xml and remove all references to the interceptor. These will look something like:

<container-configuration>
  <container-name>Standard Stateless SessionBean</container-name>
  <call-logging>false</call-logging>
  <invoker-proxy-binding-name>stateless-http-invoker</invoker-proxy-binding-name>
  <container-interceptors>
    ...
    <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>

Hibernate3 provides other mechanisms to manage Sessions (and Connections) and thus it is easy to avoid this problem.