|
|
|
|
@ -1,6 +1,7 @@
|
|
|
|
|
## 1 事务处理的编程式使用
|
|
|
|
|
```java
|
|
|
|
|
TransactionDefinition td = new DefaultTransactionDefinition();
|
|
|
|
|
// transactionManager 是某一个具体的 PlatformTransactionManager实现类 的对象
|
|
|
|
|
TransactionStatus ts = transactionManager.getTransaction(td);
|
|
|
|
|
try {
|
|
|
|
|
// 这里是需要进行事务处理的方法调用
|
|
|
|
|
@ -11,8 +12,7 @@
|
|
|
|
|
}
|
|
|
|
|
transactionManager.commit(ts);
|
|
|
|
|
```
|
|
|
|
|
在使用编程式事务处理的过程中,利用DefaultTransactionDefinition对象来持有事务处理属性。同时,在创建事务的过程中得到一个TransactionStatus对象,然后通过直接调用transactionManager的commit()和rollback()方法来完成事务处理。在这个编程式使用事务管理的
|
|
|
|
|
过程中,没有看到框架特性的使用,非常简单和直接,很好地说明了事务管理的基本实现过程,以及在Spring事务处理实现中涉及一些主要的类,比如TransationStatus、TransactionManager等,对这些类的使用与声明式事务处理的最终实现是一样的。
|
|
|
|
|
在使用编程式事务处理的过程中,利用 DefaultTransactionDefinition对象 来持有事务处理属性。同时,在创建事务的过程中得到一个 TransactionStatus对象,然后通过直接调用 transactionManager对象 的 commit() 和 rollback()方法 来完成事务处理。在这个编程式使用事务管理的过程中,没有看到框架特性的使用,非常简单和直接,很好地说明了事务管理的基本实现过程,以及在 Spring事务处理实现 中涉及一些主要的类,比如 TransationStatus、TransactionManager 等,对这些类的使用与声明式事务处理的最终实现是一样的。
|
|
|
|
|
|
|
|
|
|
与编程式使用事务管理不同,在使用声明式事务处理的时候,因为涉及 Spring框架 对事务处理的统一管理,以及对并发事务和事务属性的处理,所以采用的是一个比较复杂的处理过程,但复杂归复杂,这个过程对使用声明式事务处理的应用来说,基本上是不可见的,而是由 Spring框架 来完成的。有了这些背景铺垫和前面对 AOP封装事务处理 的了解,下面来看看 Spring 是如何提供声明式事务处理的,Spring 在这个相对较为复杂的过程中封装了什么。这层封装包括在事务处理中事务的创建、提交和回滚等比较核心的操作。
|
|
|
|
|
|
|
|
|
|
@ -104,14 +104,14 @@ public abstract class TransactionAspectSupport implements BeanFactoryAware, Init
|
|
|
|
|
```
|
|
|
|
|
在以上的处理过程之后,可以看到,具体的事务创建可以交给事务处理器来完成。在事务的创建过程中,已经为事务的管理做好了准备,包括记录事务处理状态,以及绑定事务信息和线程等。下面到事务处理器中去了解一下更底层的事务创建过程。
|
|
|
|
|
|
|
|
|
|
createTransactionIfNecessary()方法通过调用PlatformTransactionManager的getTransaction()方法,生成一个TransactionStatus对象,封装了底层事务对象的创建。可以看到,AbstractPlatformTransactionManager提供了创建事务的模板,这个模板会被具体的事务处理器所使用。从下面的代码中可以看到,AbstractPlatformTransactionManager会根据事务属性配置和当前进程绑定的事务信息,对事务是否需要创建,怎样创建 进行一些通用的处理,然后把事务创建的底层工作交给具体的事务处理器完成。尽管具体的事务处理器完成事务创建的过程各不相同,但是不同的事务处理器对事务属性和当前进程事务信息的处理都是相同的,在AbstractPlatformTransactionManager中完成了该实现,这个实现过程是Spring提供统一事务处理的一个重要部分。
|
|
|
|
|
createTransactionIfNecessary()方法 通过调用 PlatformTransactionManager 的 getTransaction()方法,生成一个 TransactionStatus对象,封装了底层事务对象的创建。可以看到,AbstractPlatformTransactionManager 提供了创建事务的模板,这个模板会被具体的事务处理器所使用。从下面的代码中可以看到,AbstractPlatformTransactionManager 会根据事务属性配置和当前进程绑定的事务信息,对事务是否需要创建,怎样创建 进行一些通用的处理,然后把事务创建的底层工作交给具体的事务处理器完成。尽管具体的事务处理器完成事务创建的过程各不相同,但是不同的事务处理器对事务属性和当前进程事务信息的处理都是相同的,在 **AbstractPlatformTransactionManager** 中完成了该实现,这个实现过程是 Spring 提供统一事务处理的一个重要部分。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
//---------------------------------------------------------------------
|
|
|
|
|
// PlatformTransactionManager的实现
|
|
|
|
|
// 实现了 PlatformTransactionManager接口 的方法
|
|
|
|
|
// 这里用了一个 模板方法模式,doGetTransaction(), doBegin() 都是交由子类实现的抽象方法
|
|
|
|
|
//---------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {
|
|
|
|
|
// doGetTransaction() 是抽象方法,Transaction对象 的取得由具体的事务管理器
|
|
|
|
|
// 实现,比如:DataSourceTransactionManager
|
|
|
|
|
@ -181,6 +181,8 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
|
|
|
|
|
事务创建的结果是生成一个 TransactionStatus对象, 通过这个对象来保存事务处理需要的基本信息,这个对象与前面提到过的 TransactionInfo对象 联系在一起, TransactionStatus 是 TransactionInfo 的一个属性,然后会把 TransactionInfo 保存在 ThreadLocal对象 里,这样当前线程可以通过 ThreadLocal对象 取得 TransactionInfo,以及与这个事务对应的 TransactionStatus对象,从而把事务的处理信息与调用事务方法的当前线程绑定起来。在 AbstractPlatformTransactionManager 创建事务的过程中,可以看到 TransactionStatus 的创建过程。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 通过给定的参数,创建一个 TransactionStatus实例
|
|
|
|
|
*/
|
|
|
|
|
@ -198,11 +200,14 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
transaction, newTransaction, actualNewSynchronization,
|
|
|
|
|
definition.isReadOnly(), debug, suspendedResources);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
新事务的创建是比较好理解的,这里需要根据事务属性配置进行创建。所谓创建,首先是把创建工作交给具体的事务处理器来完成,比如 DataSourceTransactionManager,把创建的事务对象在 TransactionStatus 中保存下来,然后将其他的事务属性和 线程ThreadLocal变量 进行绑定。
|
|
|
|
|
|
|
|
|
|
相对于创建全新事务的另一种情况是:在创建当前事务时,线程中已经有事务存在了。这种情况同样需要处理,在声明式事务处理中,在当前线程调用事务方法的时候,就会考虑事务的创建处理,这个处理在方法 handleExistingTransaction() 中完成。这里对现有事务的处理,会涉及事务传播属性的具体处理,比如 PROPAGATION_NOT_SUPPORTED、PROPAGATION_ REQUIRES_ NEW等。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 为存在的事务创建一个 TransactionStatus实例
|
|
|
|
|
*/
|
|
|
|
|
@ -256,7 +261,8 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// PROPAGATION_NESTED表示 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与PROPAGATION_REQUIRED类似的操作
|
|
|
|
|
// PROPAGATION_NESTED 表示 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,
|
|
|
|
|
// 则执行与 PROPAGATION_REQUIRED 类似的操作
|
|
|
|
|
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
|
|
|
|
|
if (!isNestedTransactionAllowed()) {
|
|
|
|
|
throw new NestedTransactionNotSupportedException(
|
|
|
|
|
@ -267,7 +273,7 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
logger.debug("Creating nested transaction with name [" + definition.getName() + "]");
|
|
|
|
|
}
|
|
|
|
|
if (useSavepointForNestedTransaction()) {
|
|
|
|
|
// 在spring管理的事务中 创建事务保存点
|
|
|
|
|
// 在 Spring 管理的事务中 创建事务保存点
|
|
|
|
|
DefaultTransactionStatus status =
|
|
|
|
|
prepareTransactionStatus(definition, transaction, false, false, debugEnabled, null);
|
|
|
|
|
status.createAndHoldSavepoint();
|
|
|
|
|
@ -311,13 +317,16 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);
|
|
|
|
|
return prepareTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
## 3 事务的挂起
|
|
|
|
|
事务的挂起牵涉线程与事务处理信息的保存,下面看一下事务挂起的实现。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 挂起给定的事务。先挂起事务同步,然后委托给doSuspend()模板方法,
|
|
|
|
|
* 挂起给定的事务。先挂起事务同步,然后委托给 doSuspend()方法,子类一般会重写该方法。
|
|
|
|
|
* 该方法返回的 SuspendedResourcesHolder对象,会作为参数传递给 TransactionStatus
|
|
|
|
|
*/
|
|
|
|
|
protected final SuspendedResourcesHolder suspend(Object transaction) throws TransactionException {
|
|
|
|
|
@ -360,13 +369,15 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
基于以上内容,就可以完成声明式事务处理的创建了。声明式事务处理能使事务处理应用的开发变得简单,但是简单的背后,蕴含着平台付出的许多努力。
|
|
|
|
|
|
|
|
|
|
## 4 事务的提交
|
|
|
|
|
下面来看看事务提交是如何实现的。有了前面的对事务创建的分析,下面来分析一下在Spring中,声明式事务处理的事务提交是如何完成的。事务提交的调用入口是TransactionInteceptor的invoke()方法,事务提交的具体实现则在其基类TransactionAspectSupport的commitTransactionAfterReturning(TransactionInfo txInfo)方法中。可以看到,txInfo是TransactionInfo对象,这个参数TransactionInfo对象是
|
|
|
|
|
创建事务时生成的。同时,Spring的事务管理框架生成的TransactionStatus对象就包含在TransactionInfo对象中。这个commitTransactionAfterReturning()方法在TransactionInteceptor的实现部分是比较简单的,它通过直接调用事务处理器来完成事务提交。
|
|
|
|
|
下面来看看事务提交是如何实现的。有了前面的对事务创建的分析,下面来分析一下在 Spring 中,声明式事务处理的事务提交是如何完成的。事务提交的调用入口是 TransactionInteceptor 的 invoke()方法,事务提交的具体实现则在其基类 TransactionAspectSupport 的 commitTransactionAfterReturning(TransactionInfo txInfo)方法 中,其中的参数 txInfo 是创建事务时生成的。同时,Spring 的事务管理框架生成的 TransactionStatus对象 就包含在 TransactionInfo对象 中。这个 commitTransactionAfterReturning()方法 在 TransactionInteceptor 的实现部分是比较简单的,它通过直接调用事务处理器来完成事务提交。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class TransactionAspectSupport implements BeanFactoryAware, InitializingBean {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 在事务方法成功调用后执行,若出现异常,则不执行。如果不创建事务,则不执行任何操作。
|
|
|
|
|
*/
|
|
|
|
|
@ -378,11 +389,14 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
与前面分析事务的创建过程一样,我们需要到事务管理器中去看看事务是如何提交的。同样,在AbstractPlatformTransactionManager中也有一个模板方法支持具体的事务管理器对事务提交的实现,在AbstractPlatformTransactionManager中,这个模板方法的实现与前面我们看到的getTransaction()很类似。
|
|
|
|
|
与前面分析事务的创建过程一样,我们需要到事务管理器中去看看事务是如何提交的。同样,在 AbstractPlatformTransactionManager 中也有一个模板方法支持具体的事务管理器对事务提交的实现,这个模板方法的实现与前面我们看到的 getTransaction() 很像。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 处理实际提交的事务
|
|
|
|
|
* 处理实际提交的事务,这是一个模板方法,其中的 doCommit() 是一个交由子类实现的抽象方法
|
|
|
|
|
*/
|
|
|
|
|
private void processCommit(DefaultTransactionStatus status) throws TransactionException {
|
|
|
|
|
try {
|
|
|
|
|
@ -463,12 +477,14 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
cleanupAfterCompletion(status);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
可以看到,事务提交的准备都是由具体的事务处理器来实现的。当然,对这些事务提交的处理,需要通过对 TransactionStatus 保存的事务处理的相关状态进行判断。提交过程涉及 AbstractPlatformTransactionManager 中的 doCommit() 和 prepareForCommit()方法,它们都是抽象方法,都在具体的事务处理器中完成实现,在下面对具体事务处理器的实现原理的分析中,可以看到对这些实现方法的具体分析。
|
|
|
|
|
|
|
|
|
|
## 5 事务的回滚
|
|
|
|
|
除了事务的创建、挂起和提交外,再来看一看事务的回滚是如何完成的。回滚处理和事务提交非常相似。
|
|
|
|
|
```java
|
|
|
|
|
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* 处理实际的事务回滚
|
|
|
|
|
*/
|
|
|
|
|
@ -523,6 +539,7 @@ public abstract class AbstractPlatformTransactionManager implements PlatformTran
|
|
|
|
|
cleanupAfterCompletion(status);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
以上对事务的创建、提交和回滚的实现原理进行了分析,这些过程的实现都比较复杂,一方面 这些处理会涉及很多事务属性的处理;另一方面 会涉及事务处理过程中状态的设置,同时在事务处理的过程中,有许多处理也需要根据相应的状态来完成。这样看来,在实现事务处理的基本过程中就会产生许多事务处理的操作分支。
|
|
|
|
|
|
|
|
|
|
|