None of the options provide a solution for the issue described in the original post:
- the fact that a JCA resource adaptor may support multiple types of the underlying connections. That means - pooling by CRI at least.
- pooling by Subject (I pressume you mean it with credantials) may cause too many sub-pools in case of a big numgber of users. The consequence is that max pool size = max pool size x number of users.
Because the original post is wrong. Read section 9.1.9.
In my opinion the pooling should depend on the re-authentication capability of adapter. If an adapter declares that it supports re-authentication - pool by CRI, if not - pool by Subject and CRI.
Wrong again.
Pooling for reauthentication enabled resource adapters is a special pool implementation (Reauth) - not PoolByCri, PoolBySubject, ...
And it is up to the resource adapter to manage its ManagedConnection connections in regards to reauthentication, so the implemented solution works.
You need to implement the contracts defined in the JCA specification - if you have multiple Connection's using the same ManagedConnection - then that it is a matter for the resource adapter - not the JCA container.