0 Replies Latest reply on Jun 12, 2009 5:41 AM by Carlo de Wolf

    CachedConnectionManager and 'late' connection closing

    Carlo de Wolf Master

      Might I breach the subject of using CachedConnectionManager and JPA again?
      Or should I now duck and cover? ;-)

      I'm encountering the infamous 'Trying to return an unknown connection2!':

      2009-06-11 05:25:32,969 TRACE [org.jboss.resource.connectionmanager.CachedConnectionManager] (http- registering connection from org.jboss.resource.connectionmanager.TxConnectionManager@31ade61, connection : org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6@16a0d419, key: org.apache.geronimo.samples.daytrader.ejb3.TradeSLSBBean@6445ac31
      2009-06-11 05:25:32,970 TRACE [org.jboss.resource.connectionmanager.CachedConnectionManager] (http- popped object: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@3e20ce61
      2009-06-11 05:25:32,972 TRACE [org.jboss.resource.connectionmanager.CachedConnectionManager] (http- unregistering connection from org.jboss.resource.connectionmanager.TxConnectionManager@31ade61, object: org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6@16a0d419, key: org.jboss.web.tomcat.service.jca.CachedConnectionValve@7171e245
      2009-06-11 05:25:32,972 INFO [org.jboss.resource.connectionmanager.TxConnectionManager] (http- throwable from unregister connection
      java.lang.IllegalStateException: Trying to return an unknown connection2! org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6@16a0d419

      As per http://www.jboss.org/community/wiki/WhydoIgetTryingtoreturnanunknownconnection2 the workaround would be to disable the cached connection interceptors/valves.

      But I think it's legit to have activity on an open connection during the first phase of a transaction commit. It might be a waste of a connection to keep it open that long, but there is no way JPA / EJB 3 can determine when people are finished using their entities.

      Consider the following scenario:
      SLSB A calls SLSB B which returns entity C.
      SLSB A then calls a lazy association on entity C.
      Thus the connection initially opened by B is used by A.

      CachedConnectionManager should take similar scenarios in mind before judging the case as faulty.