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.