Heavy access to a remote JDBC datasource (i.e. one configured with <use-java-context>false</use-java-context>) with multiple threads sometimes results in errors.

The root of this problem is how the proxied datasource objects (e.g. ResultSet, Connection, Statement, etc.) are stored in the server-side HashMap for re-use by the remote client. These objects are, not surprisingly, keyed by their respective hash code (i.e. object.hashCode()). There are cases where different objects return the same hashCode which means a remote client can close someone else's ResultSets, etc. One can easily see this by turning on DEBUG logging and executing your test. For example:

DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Created ResultSet proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=PostgresDS, cacheID=12215563
DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Created ResultSet proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=PostgresDS, cacheID=12215563
...
DEBUG [org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService] Closed ResultSet=12215563

Of course, the other client using the ResultSet whose cacheID is "12215563" will break when it tries to access it later.

To solve this problem, something other than hashCode should be used to key the HashMap entries.