CachedConnectionManager and 'late' connection closing

[wolfc]

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-10.16.43.69-8080-1) 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-10.16.43.69-8080-1) popped object: org.jboss.resource.connectionmanager.CachedConnectionManager$KeyConnectionAssociation@3e20ce61
2009-06-11 05:25:32,972 TRACE [org.jboss.resource.connectionmanager.CachedConnectionManager] (http-10.16.43.69-8080-1) 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-10.16.43.69-8080-1) 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.