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. 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.
