On Jul 18, 2006, at 10:24 AM, Joerg Heinicke wrote:
Aaron Mulder <[EMAIL PROTECTED]> writes:
Are you using a partitioned pool for the connector, set to
partition-by-connectionrequestinfo? I'm not sure if the cache
overrides that or not, but I would hope not. :)
Hello Aaron,
up to now I did not pay any attention to the pool I use, I took the
code as is
from a Jencks sample by Thierry Templier
(http://jroller.com/page/Templth?entry=jencks_in_action). And so I
only used
Jencks SinglePoolFactoryBean as well.
For testing I switched to PartitionedPoolFactoryBean and set
partitionByConnectionRequestInfo to true, but this does neither
help. Debugging
it shows why: The pool interceptor is at the end of the chain. So
for the second
request to get a connection there is no difference in behaviour of
TransactionCachingInterceptor:
ManagedConnectionInfo managedConnectionInfo =
managedConnectionInfos.getShared();
if (managedConnectionInfo != null) {
connectionInfo.setManagedConnectionInfo(managedConnectionInfo);
return;
} else {
next.getConnection(connectionInfo);
managedConnectionInfos.setShared
(connectionInfo.getManagedConnectionInfo());
}
The first request goes into the else branch, the
ManagedConnectionInfo is stored
in ManagedConnectionInfos.shared. The second request retrieves this
ManagedConnectionInfo (which is now wrong) and returns it via the
ConnectionInfo.
I think in addition you may need to specify that the resource adapter
is unshared. I'm not sure how to do this in jencks: it ought to be a
configuration option on the component that is using the connection
factory.
thanks
david jencks
Cheers,
Jörg
On 7/18/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
I have a problem with a JCA implementation of mine where I get
the same
ManagedConnection despite different ConnectionRequestInfo.
