Many storage systems (Hibernate2 / OBJ) open and close random connections. As for JBoss, it looks like one ejb assigned a connection and the other closed it. Connection closure verification does not understand this behavior. He expects the same ejb that allocated the connection to also close it.
If you use such a template or such a structure, 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 "listInUseConnections ()" in the CachedConnectionManager .
However, there is a known problem with the semantics of transaction demarcation. This is not a JBoss application, especially since ThreadLocal patterns bypass J2EE semantics.
If you encounter a problem, removing the CachedConnectionInterceptor from the interceptor stack in conf / standardjboss.xml will cost a false message. In particular, with Hibernate2 it is safe , because you can trust the sleeping state, at least to properly close the connections if you correctly execute user transactions.
To remove the CachedConnectionInterceptor, edit conf / standardjboss.xml and remove all links to the interceptor. They will look something like this:
<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 for managing sessions (and connections), and therefore this problem is easily avoided.