1 Introduction to Spring Framework Transaction Management

Comprehensive transaction support is a compelling reason to use the Spring Framework. The Spring framework provides consistent abstractions for transaction management, with the following benefits:

Consistent programming model across different transaction APIs, such as Java Transaction API (JTA), JDBC, Hibernate, Java Persistence API (JPA) and Java Data Objects ( JDO).

Supports declarative transaction management.

Simpler than complex transaction APIs (e.g., JTA).

Perfectly integrated with Spring’s data access abstraction.

2 Advantages of the Spring Framework’s transaction support model

Traditionally, Java EE developers have two optional transaction management methods: global or local transactions, each with their own limitations.

2.1 Global Transactions

Global transactions allow you to use multiple transaction resources, usually relational databases and message queues. The application manages global transactions via JTA, which is a clunky API. Also, JTA UserTransaction usually needs to come from JNDI, meaning you need to use JNDI. Obviously, using global transactions will limit the reuse of application code, because JTA is usually only available in an application server environment.

In the past, the preferred way to use global transactions was through EJB CMT (Container Managed Transactions): CMT is declarative transaction management. EJB CMT clears the JNDI lookup for related transactions, but EJB itself needs to use JNDI. It eliminates most (but not all) the need to write Java code to control transactions. The important disadvantage is that CMT bundles JTA and application server environments. At the same time, it only works when using EJBs to implement business logic, or at least within a transactional EJB facade.

2.2 Local transactions

Local transactions are specific resources, for example, transactions are associated with JDBC connections. Local transactions are easy to use, but have a significant disadvantage: they cannot span multiple transaction resources. For example, transactions managed using a JDBC connection cannot run within a global JTA transaction. Because the application server is not responsible for transaction management, it does not guarantee correctness across resources. Another disadvantage is the intrusive programming model of local transactions.

2.3 The consistent programming model of the Spring framework

Spring solves the shortcomings of global and local transactions. It allows developers to use a consistent programming model in any environment. Developers only need to write their own code, which abstracts away different transaction management in different environments. The Spring framework provides declarative and programmatic transaction management. Most users prefer declarative transaction management, which is also recommended.

Using programmatic transaction management, developers use Spring framework transaction abstraction and can run on any underlying transaction. Using the preferred declarative model, developers typically write little or no transaction management code and, therefore, do not rely on the Spring Framework transaction API, or other transaction APIs.

3 The key to understanding the Spring framework transaction abstraction

Spring transaction abstraction is the concept of transaction strategy. Transaction strategy is defined through the org.springframework.transaction.PlatformTransactionManager interface:

public interface PlatformTransactionManager {

?TransactionStatus getTransaction(

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? using using using org.springframework.transaction. ? ? ? ? ????‐ ‐ ‐ ‐‐‐‐‐‐‐‐‐‐ void commit(TransactionStatus status) throws TransactionException;

?????? void rollback(TransactionStatus status) throws TransactionException;

}

This is primarily a Service Provider Interface (SPI), although it can use the programming model in your code. Because PlatformTransactionManager is an interface, it is easy to mock and stubbed. It does not require a lookup strategy like JNDI. PlatformTransactionManager is implemented like other objects defined in the Spring IoC container. This benefit makes Spring Framework transactions worth abstracting, even when using JTA. Transaction code is easier to test than using JTA directly.

The TransactionException thrown by the PlatformTransactionManager interface method is an undetected exception (that is, it inherits java.lang.RuntimeException). Transaction failure is fatal. In the rare cases where application code can actually recover from a transaction failure, the application developer can choose to catch and handle TransactionException. The advantage is that developers don't have to force this.

The getTransaction(..) method relies on the TransactionDefinition parameter to return the TransactionStatus object. The returned TransactionStatus can represent a new transaction, or an existing transaction if the matching transaction exists in the current call stack. In fact, this is the latter case. Just like the Java EE transaction context, TransactionStatus is associated with executable transactions.

TransactionDefinition interface description:

Isolation (transaction isolation level): Transaction isolation level. For example, can this transaction read other uncommitted transactions?

Propagation (transaction propagation): Normally, all code executed in transaction scope will run within the transaction. However, you have an option to specify the behavior of transaction method execution when a transaction context already exists. For example, the code can continue to run in an existing transaction (the usual situation); or the existing transaction can be paused and a new transaction created.

Transaction timeout: How long does the transaction run before it expires and is automatically rolled back through the underlying transaction.

Read-only state: Read-only transactions can be used when your code reads but does not modify data. In some cases, read-only transactions are beneficial for optimization, for example, when you use Hibernate.

These settings reflect standard transaction concepts. These underlying concepts are integral to using the Spring Framework or any transaction management solution.

The TransactionStatus interface provides a simple way for transaction code to control executable transactions and query transaction status:

public interface TransactionStatus extends SavepointManager {

boolean isNewTransaction();

boolean hasSavepoint();

void setRollbackOnly();

boolean isRollbackOnly();

void flush();

boolean isCompleted();

Whether you choose declarative or programmatic in Spring For platform transaction management, it is essential to define the correct PlatformTransactionManager implementation. You typically define this implementation via dependency injection.

PlatformTransactionManager usually needs to know the working environment: JDBC, JTA, Hibernate, etc. Below is an example of defining a local PlatformTransactionManager.

Define JDBC DataSource:

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? using use using ‐ ? ? ? ? ? ? ? ? ? ? ? ? out out out through out's off out's off ’s ‐ to ‐‐‐‐‐‐ andlt; value="${jdbc.driverClassName}" />

?

? ;bean id="txManager"

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

If you are using JTA in a Java EE container, then you can get the container's DataSource by using JNDI and Spring's JtaTransactionManager:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:jee= "http://www.springframework.org/schema/jee"

???????????????????????????????????????????????????????????????????/beans/spring-beans.xsd

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

?

?

?

JtaTransactionManager does not need to know about the DataSource, or any specific resource, because it uses the container's global transaction management.

You can also use Hibernate’s local transactions. In this case, you need to define Hibernate's LocalSessionFactoryBean, which your application code will use to obtain a Hibernate Session instance.

In this case, the txManager bean is HibernateTransactionManager. Just as the DataSourceTransactionManager needs to reference the DataSource, the HibernateTransactionManager needs to reference the SessionFactory:

????

????

????????

????????????org/springframework/samples/petclinic/hibernate/petclinic.hbm.xml

????????

????

????

????????

????????????hibernate.dialect=${hibernate.dialect}

????????

????

???

?如果你使用Hibernate和Java EE容器管理JTA事務(wù)，那么你只用使用JtaTransactionManager：

在所有這些情況下，應(yīng)用程序代碼不需要改變。你僅僅需要改變配置來改變?nèi)绾喂芾硎聞?wù)。

4????使用事務(wù)同步資源

現(xiàn)在應(yīng)該清楚如何創(chuàng)建不同的事務(wù)管理器，和它們?nèi)绾捂溄有枰绞聞?wù)的相關(guān)資源（例如，DataSourceTransactionManager鏈接DataSource，HibernateTransactionManager鏈接SessionFactory等等）。

4.1??? 高級同步方式

首選方式是使用Spring的高級模板基于持久化集成APIs或使用帶有事務(wù)的本地ORM APIs——感知工廠bean或代理管理本地資源工廠。這些事務(wù)感知解決方案內(nèi)部處理資源創(chuàng)建、重用、清理、資源事務(wù)同步選項(xiàng)和異常映射。因此，數(shù)據(jù)訪問代碼沒有處理這些任務(wù)，但可以關(guān)注非樣板式持久化邏輯。通常，你使用本地ORM API或通過使用JdbcTemplate獲取模板。

4.2??? 低級同步方式

例如，DataSourceUtils（JDBC）、EntityManagerFactoryUtils（JPA）、SessionFactoryUtils（Hibernate）、PersistenceManagerFactoryUtils（JDO）存在底層同步方式。當(dāng)你想應(yīng)用程序代碼直接處理本地持久化APIs，你使用這些類確保獲取Spring框架管理的實(shí)例，事務(wù)是（可選）同步的，發(fā)生在進(jìn)程中的異常正確映射一致性API。

例如，在JDBC的情況下，傳統(tǒng)的JDBC方式在DataSource上調(diào)用getConnection()方法，你可以使用Spring的org.springframework.jdbc.datasource.DataSourceUtils：

Connection conn = DataSourceUtils.getConnection(dataSource);

如果已存在的事務(wù)已經(jīng)有一個連接同步（鏈接）它，實(shí)例被返回。否則，方法調(diào)用觸發(fā)器創(chuàng)建新的連接，（可選）同步任意已存在的事務(wù)，后續(xù)在相同事務(wù)中重用。

這種方式不需要Spring事務(wù)管理（事務(wù)同步是可選的），因此，無論你是否使用Spring管理事務(wù)你都能使用它。

當(dāng)然，一旦你使用Spring的JDBC支持、JPA支持或Hibernate支持，你通常不喜歡使用DataSourceUtils或其它的幫助類。

4.3????TransactionAwareDataSourceProxy

在底層，已經(jīng)存在TransactionAwareDataSourceProxy類。這是目標(biāo)DataSource代理，包裝目標(biāo)DataSource到感知Spring管理事務(wù)。為此，它類似于Java EE服務(wù)器提供的傳統(tǒng)JNDI DataSource。

5????聲明式事務(wù)管理

Spring框架的聲明式事務(wù)管理讓Spring面向切面編程（AOP）成為可能，盡管，Spring框架發(fā)布包以模板形式自帶事務(wù)切面代碼，一般需要理解AOP。

5.1????理解Spring框架的聲明式事務(wù)實(shí)現(xiàn)

通過元數(shù)據(jù)驅(qū)動事務(wù)通知（當(dāng)前基于XML或注解）。AOP聯(lián)合事務(wù)元數(shù)據(jù)產(chǎn)生AOP代理，使用TransactionInterceptor聯(lián)合適當(dāng)?shù)腜latformTransactionManager實(shí)現(xiàn)驅(qū)動事務(wù)環(huán)繞方法調(diào)用。

5.2?Example of declarative transaction implementation

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:aop="http://www.springframework.org/schema/aop"

xmlns:tx ="http://www.springframework.org/schema/tx"

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?schema/beans/spring-beans.xsd

???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????/www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring- aop.xsd"> ;

& lt;-& gt;

& lt;

& lt; ;tx:advice id="txAdvice" transaction-manager="txManager">

?????????????????????????????????????????????????????????????????????????????????????????????????????????????????tx:method name="get*" read-only="true"/> " execution(* x.y.service.FooService .*(..)) "/& gt;

& lt; AOP: Advisor Advice-Ref =" TXADVICE "POINTCUT-Ref =" FooserviceOperation "/& GT;

& LT;/AOP: Config & LT & LT & LT ;; bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

?????

????????????????????????????????????????????????????????????????????????????????????????????????????????? ">

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????,,,,,,,,,, Causes Spring transaction rollback when a runtime exception or Error is thrown. Checked exceptions do not cause Spring transactions to be rolled back.

You can explicitly configure the exception type for transaction rollback.

???????????????????????????????????????????????????????-for="NoProductInStockException"/>

??????????????????????????????????????????????????????????????

5.4 Configure different transaction semantics for different beans

?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

?xmlns:aop="http://www?/beans

?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????schema / tx/spring-tx.

????????????????????????? ="noTxServiceOperation" expression="execution(* x.y.service.ddl.DefaultDdlManager.*(..))"/>

???????????????????????????????????????????????????????????????????????????????????????????????????????;

??????????????????????????????????????????????????????????????????????????????????????????????????????????????????advisor pointcut-ref="noTxServiceOperation"????????????????????????????????????????????????.

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

???????????????????????????????????????????????????????????????????????????????????????????????

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

Transaction propagation setting is REQUIRED

Transaction isolation level is DEFAULT

Transaction is read/write

Transaction timeout defaults to the timeout of the underlying transaction system, or none if timeout is not supported

Any RuntimeException triggers rollback , any check Exception does not trigger

You can change these default settings; the various tags nested in the and tags Properties:

5.6 Using @Transactional

Enable annotation management:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:aop="http://www.springframework.org/schema/aop"

xmlns:tx=" http://www.springframework.org/schema/tx" beans/spring-beans.xsd

?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring- aop.xsd">

& lt; ---- & gt;

;

?

?

? Declaration annotation:

@Transactional

public class DefaultFooService implements FooService {

Foo getFoo(String fooName);

Foo getFoo(String fooName, String barName);

void insertFoo(Foo foo) ;

void updateFoo(Foo foo);

}

@Transactional settings:

@Transactional’s multi-transaction manager:

public class TransactionalService {

@Transactional("order" )

? public void setSomething(String name) { ... }

@Transactional("account")

public void doSomething() { ... }

}

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

...

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

...

Custom abbreviation annotation

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Transactional("order")

public @interface OrderTx {

}

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Transactional("account")

public @interface AccountTx {

}

5.7 Transaction Propagation

PROPAGATION_REQUIRED

When setting transaction propagation to PROPAGATION_REQUIRED, a logical transaction scope is created for each method. Each logical transaction scope can independently determine the rollback state, and the outer transaction scope logic is independent of the inner transaction scope. Of course, in the standard PROPAGATION_REQUIRED case, all these scopes will map to the same physical transaction. Therefore, only setting the rollback flag in the inner transaction scope does not affect the actual commit of the outer transaction that occurs.

However, in this case, the inner transaction scope is set to the rollback mark only, the outer transaction did not decide to rollback, so the rollback is unexpected. The corresponding UnexpectedRollbackException is thrown.

PROPAGATION_REQUIRES_NEW

Compared with PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW uses a completely independent transaction. In this case, the underlying physical transaction is different and, therefore, can be committed or rolled back independently, and the rollback status of the outer transaction is not affected by the inner transaction.

PROPAGATION_NESTED

Use a physics transaction that can roll back to multiple savepoints. This rollback allows the inner transaction scope to trigger a rollback of its scope and the outer transaction to be able to continue the physical transaction even though some operations have been rolled back. This setting is typically mapped to a JDBC savepoint and, therefore, can only be used for JDBC resource transactions.

6 same way.

public class SimpleService implements Service {

private final TransactionTemplate transactionTemplate;

public SimpleService(PlatformTransactionManager transactionManager) {

Assert.notNull(transactionManager, "The ' Manager' argument must not be null."); R this.TRANSACTIONTEMPLATE = New TransactionTemplate (TransactionManager);

}

E.Execute (New TransactionCallback () {

Public Object Dointransaction (TransactionStatus Status) {

UpdateOperation1 ();

????????????????????????????????????????? return resultOfUpdateOperation2(); Result class:

transactionTemplate.execute(new TransactionCallbackWithoutResult() {

protected void doInTransactionWithoutResult(TransactionStatus status) {

??????????????????????????????????????????????????????????????????; (new TransactionCallbackWithoutResult() {

T ProteCted Void DointransactionWithoutResult (TransactionStatus Status) {

Try {

UpdateOperation1 (); Sexepting ex) {

Status.SetrolllLLLLLLLLY ();

}}}

});

Specify transaction settings:

public class SimpleService implements Service {

?private final TransactionTemplate transactionTemplate;

?public SimpleService(PlatformTransactionManager transactionManager) {

??Assert. notNull(transactionManager, "The 'transactionManager' argument must not be null.");

this.transactionTemplate = new TransactionTemplate(transactionManager);

this.transactionTemplate.setIsolationLevel(

TransactionDefinition.ISOLATION_READ_UNCOMMITTED);

this .transactionTemplate.setTimeout(30); // 30 Seconds

}

}

Configure TransactionTemplate using Spring XML:

class="org.springframework.transaction.support.TransactionTemplate">

6.2 Using PlatformTransactionManager

DefaultTransactionDefinition def = new DefaultTransactionDefinition();

def.setName("SomeTxName");

def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

TransactionStatus status = txManager.getTransaction(def);

try {

/ / Execute business logic

} catch (MyException ex) {

txManager.rollback(status);

throw ex;

}

txManager.commit(status);

7 Choose programmatic or declarative management of transactions ?

If you only have a small number of transaction operations, choose programmatic transaction management.

8 Transaction Binding Events

Starting from Spring 4.2, listener events can be bound to transaction phases.

@Component public class MyComponent {

???????? @TransactionalEventListener

????? public void handleOrderCreatedEvent(CreationEvent creationEvent) {

?????????????????????????????????????????????

}

TransactionalEventListener annotation exposes phase attribute to allow customized listening transactions stage. Valid phases are: BEFORE_COMMIT, AFTER_COMMIT (default), AFTER_ROLLBACK and AFTER_COMPLETION.