CciLocalTransactionManager

org.springframework.transaction.PlatformTransactionManager implementation that manages local transactions for a single CCI ConnectionFactory. Binds a CCI Connection from the specified ConnectionFactory to the thread, potentially allowing for one thread-bound Connection per ConnectionFactory.

Application code is required to retrieve the CCI Connection via ConnectionFactoryUtils#getConnection(ConnectionFactory) instead of a standard Java EE-style ConnectionFactory#getConnection() call. Spring classes such as org.springframework.jca.cci.core.CciTemplate use this strategy implicitly. If not used in combination with this transaction manager, the ConnectionFactoryUtils lookup strategy behaves exactly like the native DataSource lookup; it can thus be used in a portable fashion.

Alternatively, you can allow application code to work with the standard Java EE lookup pattern ConnectionFactory#getConnection(), for example for legacy code that is not aware of Spring at all. In that case, define a TransactionAwareConnectionFactoryProxy for your target ConnectionFactory, which will automatically participate in Spring-managed transactions.

ConnectionHolder

Connection holder, wrapping a CCI Connection.

CciLocalTransactionManager binds instances of this class to the thread, for a given ConnectionFactory.

Note: This is an SPI class, not intended to be used by applications.

ConnectionSpecConnectionFactoryAdapter

An adapter for a target CCI javax.resource.cci.ConnectionFactory, applying the given ConnectionSpec to every standard getConnection() call, that is, implicitly invoking getConnection(ConnectionSpec) on the target. All other methods simply delegate to the corresponding methods of the target ConnectionFactory.

Can be used to proxy a target JNDI ConnectionFactory that does not have a ConnectionSpec configured. Client code can work with the ConnectionFactory without passing in a ConnectionSpec on every getConnection() call.

In the following example, client code can simply transparently work with the preconfigured "myConnectionFactory", implicitly accessing "myTargetConnectionFactory" with the specified user credentials.

 <bean id="myTargetConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName" value="java:comp/env/cci/mycf"/> </bean> <bean id="myConnectionFactory" class="org.springframework.jca.cci.connection.ConnectionSpecConnectionFactoryAdapter"> <property name="targetConnectionFactory" ref="myTargetConnectionFactory"/> <property name="connectionSpec"> <bean class="your.resource.adapter.ConnectionSpecImpl"> <property name="username" value="myusername"/> <property name="password" value="mypassword"/> </bean> </property> </bean>

If the "connectionSpec" is empty, this proxy will simply delegate to the standard getConnection() method of the target ConnectionFactory. This can be used to keep a UserCredentialsConnectionFactoryAdapter bean definition just for the option of implicitly passing in a ConnectionSpec if the particular target ConnectionFactory requires it.

NotSupportedRecordFactory

Implementation of the CCI RecordFactory interface that always throws NotSupportedException.

Useful as a placeholder for a RecordFactory argument (for example as defined by the RecordCreator callback), in particular when the connector's ConnectionFactory.getRecordFactory() implementation happens to throw NotSupportedException early rather than throwing the exception from RecordFactory's methods.

SingleConnectionFactory

A CCI ConnectionFactory adapter that returns the same Connection on all getConnection calls, and ignores calls to Connection.close().

Useful for testing and standalone environments, to keep using the same Connection for multiple CciTemplate calls, without having a pooling ConnectionFactory, also spanning any number of transactions.

You can either pass in a CCI Connection directly, or let this factory lazily create a Connection via a given target ConnectionFactory.

TransactionAwareConnectionFactoryProxy

Proxy for a target CCI javax.resource.cci.ConnectionFactory, adding awareness of Spring-managed transactions. Similar to a transactional JNDI ConnectionFactory as provided by a Java EE server.

Data access code that should remain unaware of Spring's data access support can work with this proxy to seamlessly participate in Spring-managed transactions. Note that the transaction manager, for example the CciLocalTransactionManager, still needs to work with underlying ConnectionFactory, not with this proxy.

Make sure that TransactionAwareConnectionFactoryProxy is the outermost ConnectionFactory of a chain of ConnectionFactory proxies/adapters. TransactionAwareConnectionFactoryProxy can delegate either directly to the target connection pool or to some intermediate proxy/adapter like ConnectionSpecConnectionFactoryAdapter.

Delegates to ConnectionFactoryUtils for automatically participating in thread-bound transactions, for example managed by CciLocalTransactionManager. getConnection calls and close calls on returned Connections will behave properly within a transaction, i.e. always operate on the transactional Connection. If not within a transaction, normal ConnectionFactory behavior applies.

This proxy allows data access code to work with the plain JCA CCI API and still participate in Spring-managed transactions, similar to CCI code in a Java EE/JTA environment. However, if possible, use Spring's ConnectionFactoryUtils, CciTemplate or CCI operation objects to get transaction participation even without a proxy for the target ConnectionFactory, avoiding the need to define such a proxy in the first place.

NOTE: This ConnectionFactory proxy needs to return wrapped Connections in order to handle close calls properly. Therefore, the returned Connections cannot be cast to a native CCI Connection type or to a connection pool implementation type.