Spring is a popular framework for developing Java™ applications. WebSphere® eXtreme Scale provides support to
allow Spring to manage eXtreme Scale transactions
and configure eXtreme Scale clients
and servers.
About this task
The Spring Framework is highly integrable with
eXtreme Scale, as discussed in
the following sections.
Procedure
- Native transactions: Spring provides container-managed
transactions along the style of a Java Platform, Enterprise Edition application server
but has the advantage that Springs mechanism can have different implementations
plugged in. This topic describes an eXtreme Scale Platform Transaction
manager that can be used with Spring. This allows programmers to annotate
their POJOs (plain old Java objects)
and then have Spring automatically acquire Sessions from eXtreme Scale and begin, commit,
rollback, suspend, and resume eXtreme Scale transactions. Spring
transactions are described more fully in Chapter 10 of the official Spring reference documentation.
The following explains how to create an eXtreme Scale transaction manager
and use it with annotated POJOs. It also explains how to use this
approach with client or local eXtreme Scale as well as a collocated
Data Grid style application.
- Transaction manager: To work with Spring,, eXtreme Scale provides an implementation
of a Spring PlatformTransactionManager. This manager can provide managed eXtreme Scale sessions to POJOs
managed by Spring. Through the use of annotations, Spring manages
those sessions for the POJOs in terms of transaction life cycle. The
following XML snippet shows how to create a transaction Manager:
<aop:aspectj-autoproxy/>
<tx:annotation-driven transaction-manager="transactionManager"/>
<bean id="ObjectGridManager"
class="com.ibm.websphere.objectgrid.ObjectGridManagerFactory"
factory-method="getObjectGridManager"/>
<bean id="ObjectGrid"
factory-bean="ObjectGridManager"
factory-method="createObjectGrid"/>
<bean id="transactionManager"
class="com.ibm.websphere.objectgrid.spring.ObjectGridSpringFactory"
factory-method="getLocalPlatformTransactionManager"/>
</bean>
<bean id="Service" class="com.ibm.websphere.objectgrid.spring.test.TestService">
<property name="txManager" ref+"transactionManager"/>
</bean>
This shows the transactionManager bean being
declared and wired in to the Service bean that will use Spring transactions.
We will demonstrate this using annotations and this is the reason
for the tx:annotation clause at the beginning.
- Obtaining an ObjectGrid session:
A
POJO that has methods managed by Spring can now obtain the ObjectGrid
session for the current transaction using Session s = txManager.getSession();
This
returns the session for the POJO to use. Beans participating in the
same transaction will receive the same session when they call this
method. Spring will automatically handle begin for the Session and
also automatically invoke commit or rollback when necessary. You can
obtain an ObjectGrid EntityManager also by simply calling getEntityManager
from the Session object.
- Setting the ObjectGrid instance for a thread: A
single Java Virtual Machine
(JVM) can host many ObjectGrid instances. Each primary shard placed
in a JVM has its own ObjectGrid instance. A JVM acting as a client
to a remote ObjectGrid uses an ObjectGrid instance returned from the
connect method's ClientClusterContext to interact with that Grid.
Before invoking a method on a POJO using Spring transactions for ObjectGrid,
the thread must be primed with the ObjectGrid instance to use. The
TransactionManager instance has a method allowing a specific ObjectGrid
instance to be specified. Once specified then any subsequent txManager.getSession calls
will returns Sessions for that ObjectGrid instance.
The
following example shows a sample main for exercising this capability:
ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext(new String[]
{"applicationContext.xml"});
SpringLocalTxManager txManager = (SpringLocalTxManager)ctx.getBean("transactionManager");
txManager.setObjectGridForThread(og);
ITestService s = (ITestService)ctx.getBean("Service");
s.initialize();
assertEquals(s.query(), "Billy");
s.update("Bobby");
assertEquals(s.query(), "Bobby");
System.out.println("Requires new test");
s.testRequiresNew(s);
assertEquals(s.query(), "1");
Here we use a Spring
ApplicationContext. The ApplicationContext is used to obtain a reference
to the txManager and specify an ObjectGrid to use on this thread.
The code then obtains a reference to the service and invokes methods
on it. Each method call at this level causes Spring to create a Session
and do begin/commit calls around the method call. Any exceptions will
cause a rollback.
- SpringLocalTxManager interface: The SpringLocalTxManager
interface is implemented by the ObjectGrid Platform Transaction Manager
and has all public interfaces. The methods on this interface are for
selecting the ObjectGrid instance to use on a thread and obtaining
a Session for the thread. Any POJOs using ObjectGrid local transactions
should be injected with a reference to this manager instance and only
a single instance need be created, that is, its scope should be singleton.
This instance is created using a static method on ObjectGridSpringFactory.
getLocalPlatformTransactionManager().
Restriction: WebSphere eXtreme Scale does
not support JTA or two-phase commit for various reasons mainly to
do with scalability. Thus, except at a last single-phase participant,
ObjectGrid does not interact in XA or JTA type global transactions.
This platform manager is intended to make using local ObjectGrid transactions
as easy as possible for Spring developers.