Spring Summary-Transaction Management

In traditional J2EE applications, transaction management is bound with EJB. At that time, most people only use the local slsb of EJB to use its declarative transaction management. With the continuous development of technology, such as the emergence of spring, many core J2EE concepts have to begin introspection, and it is more reasonable to improve ourselves under the impact of spring. Therefore, JTA is not dedicated to ejbs and is opposite to local
Transaction has also been paid more attention when it is more suitable.

Here is a brief summary of spring's transaction management. In the traditional J2EE, the transaction management solution is global container management transactions. transactions are coordinated by the application server, and the server registers all the resources involved in the transaction, submit or roll back the service method as needed. A typical example is EJB.
The advantage of CMT is that it moves the tedious transaction management function to the EJB deployment descriptor, and the transaction management becomes a cross-section without hard coding. Of course, it also has fatal disadvantages: only ejbs can be used, heavyweight global transaction management must be used, and a small amount of transactions are useless ......

Spring transaction management involves the original intention: (what we need ?)

1. Programmable Transaction Management and consistent exception handling mechanism.

2. Declarative transactions implemented on pojo do not need to be bound to heavyweight component models

3. pluggable transaction policies and means to allow resources to join transactions freely

4. JTA support for Distributed containers

5. Data source components provided for integration of various ORM frameworks

The following describes the composition of spring's transaction framework, with three core interfaces: transactiondefinition, transactionstatus, and platformtransactionmanager. Their respective functions are as follows:

Transactiondefinition

Encapsulate the settings of all transaction-related attributes. The Attributes provided for the transaction isolation level include isolation_default, isolation_read_uncommitted, isolation_read_committed, and isolation_serializable. Six propagation attributes are provided for transaction propagation: propagation_required, propagation_supports, propagation_mandatory, propagation_requires_new, propagation_not_support, and propagation_nested. If you have used EJB, you will find that this is basically the same as EJB.
The CMT is consistent.

Transactionstatus

It allows the Transaction Manager to control transaction execution. There are only three interface methods: isnewtransaction (), setrollbackonly (), and isrollbackonly (). Setrollbackonly rolls back the current transaction and terminates it.

Platformtransactionmanager

This is the planner of transaction management. It uses the first two interfaces to create and manage transactions. It provides three methods: gettransaction (), commit (), and rollback (). It returns a transactionstatus object for a given transactiondefinition, and triggers the submit or rollback operation on this state object. For manual programming-based transaction management, it is basically to operate the coding of the implementation classes of these three interfaces in the code block between try/catch to write resource access code, the transaction execution result is the submission or rollback of the manager object.

TransactionDefinition definition = new DefaultTransactionDefinition();//set definition features here //… TransactionStatus status = transactionManager.getTransaction(definition);try{     //do some resource access      //or business logical use these resource }catch(BusinessException ex){     transactionManager.rollback(status);     throw ex;}transactionManager.commit(status);//return some result 

Programming-style transaction management requires tedious coding, which is not a common method. We mainly look at the more lightweight and efficient declarative Transaction Management (declarative transactions ). The explicit expression in the spring container means that we need to inform a method of a bean in spring that transaction management is required. Then, spring will ensure that there are transactions throughout the method when it is called. This implementation method relies on AOP to intercept method calls. Spring provides two declarative methods to create a transaction management proxy (Dynamic proxy is the core of AOP): proxyfactorybean and transactionproxyfactorybean. Let's look at two examples:

<Beans> <bean id = "mytransactionmanager" class = "org. springframework. transaction. JTA. jtatransactionmanager "/> <bean id =" businessobjecttarget "class =" business. businessobject "/> <bean id =" transactioninterceptor "class =" Org. springframework. transaction. interceptor. transactioninterceptor "> <property name =" transactionmanager "> <ref bean =" mytransactionmanager "/> </property> <property name =" transactionattrib Utesource "> <value> business. businessobject. Method1 = propagation_required,-response. businessobject. method2 = propagation_required, + businesscheckedexception </value> </property> </bean>! -Cglib is used implicitly, and the integrated proxy object is used as a subclass proxy --> <bean id = "mybusinessobject" class = "org. springframework. AOP. framework. proxyfactorybean "> <property name =" interceptornames "> <value> mytransactioninterceptor, businessobjecttarget </value> </property> </bean> <! -The JDK built-in dynamic proxy is displayed. You must specify the proxy interface and choose one from the previous Bean --> <bean id = "mybusinessobject" class = "org. springframework. AOP. framework. proxyfactorybean "> <property name =" proxyinterfaces "> <value> business. businessinterface </value> </property> <property name = "interceptornames"> <value> mytransactioninterceptor, businessobjecttarget </value> </property> </bean> </beans>

Let's look at another declarative transaction management method configured using transactionproxyfactorybean:

<beans>     <bean id=”myTransactionManager” class=”org.springframework.transaction.jta.JtaTransactionManager”/>    <bean id=”businessObjectTarget” class=”business.BusinessObject”/>    <bean id=”myBusinessObject” class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”>        <property name=”transactionManager”>            <refref=”myTransactionManager”/>        </property>        <property name=”target”>            <ref bean=” businessObjectTarget”/>        </property>        <property name=”transactionAttributes”>           <props>             <prop key=”businessMethod1”>PROGATION_REQUIRE, -BusinessCheckedException</prop>           </props>        </property>    </bean></beans>

Compared with the previous configuration method, this configuration method has the advantage of organizing all the configuration items and defining the transaction attributes in the proxy class. It is equivalent to integrating transactioninterceptor and proxyfactorybean. You can also use the built-in JDK or cglib proxy. You can use the cglib proxy mode by specifying proxytargetclass to true.

 

In general, spring's transaction management is like this. It is noted that all transaction attributes are specified in the transactionattributes or transactionattributesource in the configuration file in the form of key-value, however, currently, a more popular method is to set transaction attributes through source code-level metadata. This is an example of spring and openjpa integration I have previously written.