修缮之前的博文
This commit is contained in:
AmyliaY
parent
dd753a604b
commit
49b7bef419
@ -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);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
以上对事务的创建、提交和回滚的实现原理进行了分析，这些过程的实现都比较复杂，一方面 这些处理会涉及很多事务属性的处理；另一方面 会涉及事务处理过程中状态的设置，同时在事务处理的过程中，有许多处理也需要根据相应的状态来完成。这样看来，在实现事务处理的基本过程中就会产生许多事务处理的操作分支。
|
||||
|
||||
|
||||
@ -1,20 +1,15 @@
|
||||
## 1 Spring事务处理的应用场景
|
||||
下面，我们以DataSourceTransactionManager事务管理器为例，看一下在具体的事务管理器中如何实现事务创建、提交和回滚这些底
|
||||
层的事务处理操作。DataSourceTransationManager和其他事务管理器一样，如JtaTransactionManager，JpaTransactionManager和JdoTransactionManager，都继承自AbstractPlatformManager，作为一个基类，AbstractPlatfromManager封装了Spring事务处理中通用的处理部分，比如事务的创建、提交、回滚，事务状态和信息的处理，与线程的绑定等，有了这些通用处理的支持，对于具体的事务管理器而言，它们只需要处理和具体数据源相关的组件设置就可以了，比如在HibernateTransactionManager中，就只需要配置好和Hibnernate事务处理相关的接口以及相关的设置。所以，从PlatformTransactionManager组件的设计关系上，我们也可以看到，Spring事务处理的主要过程是分两个部分完成的，通用的事务处理框架是在AbstractPlatformManager中完成，而Spring的事务接口与数据源实现的接口，多半是由具体
|
||||
的事务管理器来完成，它们都是作为AbstractPlatformManager的子类来是使用的。
|
||||
下面，我们以 DataSourceTransactionManager事务管理器 为例，看一下在具体的事务管理器中如何实现事务创建、提交和回滚这些底层的事务处理操作。DataSourceTransationManager 和其他事务管理器一样，如 JtaTransactionManager，JpaTransactionManager 和 JdoTransactionManager，都继承自 AbstractPlatformManager，作为一个基类，AbstractPlatfromManager 封装了 Spring事务处理 中通用的处理部分，比如事务的创建、提交、回滚，事务状态和信息的处理，与线程的绑定等，有了这些通用处理的支持，对于具体的事务管理器而言，它们只需要处理和具体数据源相关的组件设置就可以了，比如在 HibernateTransactionManager 中，就只需要配置好和 Hibnernate事务处理 相关的接口以及相关的设置。所以，从 PlatformTransactionManager组件 的设计关系上，我们也可以看到，Spring事务处理 的主要过程是分两个部分完成的，通用的事务处理框架是在 AbstractPlatformManager 中完成，而 Spring 的事务接口与数据源实现的接口，多半是由具体的事务管理器来完成，它们都是作为 AbstractPlatformManager 的子类来是使用的。
|
||||
|
||||
可以看到，在PlatformTransactionManager组件的设计中 ，通过PlatformTransactionManager接口 设计了一系列与事务处理息息相关的接口方法，如getTransaction()、commit()、rollback()这些和事务处理相关的统一接口。对于这些接口的实现，很大一部分是由AbstractTransactionManager抽象类来完成的，这个类中的doGetTransaction()、doCommit()等方法和PlatformTransactionManager的方法
|
||||
对应，实现的是事务处理中相对通用的部分。在这个AbstractPlatformManager下，为具体的数据源配置了不同的事务处理器，以处理不同数据源的事务处理，从而形成了一个从抽象到具体的事务处理中间平台设计，使应用通过声明式事务处理，即开即用事务处理服务，隔离那些与特定的数据源相关的具体实现。
|
||||
可以看到，在 PlatformTransactionManager组件 的设计中 ，通过 PlatformTransactionManager接口 设计了一系列与事务处理息息相关的接口方法，如 getTransaction()、commit()、rollback() 这些和事务处理相关的统一接口。对于这些接口的实现，很大一部分是由 AbstractTransactionManager抽象类 来完成的，这个类中的 doGetTransaction()、doCommit() 等方法和 PlatformTransactionManager 的方法对应，实现的是事务处理中相对通用的部分。在这个 AbstractPlatformManager 下，为具体的数据源配置了不同的事务处理器，以处理不同数据源的事务处理，从而形成了一个从抽象到具体的事务处理中间平台设计，使应用通过声明式事务处理，即开即用事务处理服务，隔离那些与特定的数据源相关的具体实现。
|
||||
|
||||
|
||||
|
||||
## 2 DataSourceTransactionManager的实现
|
||||
我们先看一下DataSourceTransactionManager，在这个事务管理器中，它的实现直接与事务处理的底层实现相关。在事
|
||||
务开始的时候，会调用doBegin()方法，首先会得到相对应的Connection，然后可以根据事务设置的需要，对Connection的相关属性进行配置，比如将Connection的autoCommit功能关闭，并对像TimeoutInSeconds这样的事务处理参数进行设置，最后通过TransactionSynchronizationManager来对资源进行绑定。
|
||||
我们先看一下 DataSourceTransactionManager，在这个事务管理器中，它的实现直接与事务处理的底层实现相关。在事务开始的时候，会调用 doBegin()方法，首先会得到相对应的 Connection，然后可以根据事务设置的需要，对 Connection 的相关属性进行配置，比如将 Connection 的 autoCommit功能 关闭，并对像 TimeoutInSeconds 这样的事务处理参数进行设置，最后通过 TransactionSynchronizationManager 来对资源进行绑定。
|
||||
|
||||
从下面的代码中可以看到，DataSourceTransactionManager 作为 AbstractPlatformTransactionManager 的子类，在 AbstractPlatformTransactionManager 中已经为事务实现设计好了一系列的模板方法，比如 事务的提交、回滚处理等。在 DataSourceTransactionManager 中， 可以看到对模板方法中一些抽象方法的具体实现。例如，由 DataSourceTransactionManager 的 doBegin()方法 实现负责事务的创建工作。具体来说，如果使用 DataSource 创建事务，最终通过设置 Connection 的 autoCommit属性 来对事务处理进行配置。在实现过程中，需要把数据库的 Connection 和当前的线程进行绑定。对于事务的提交和回滚，都是通过直接调用 Connection 的提交和回滚来完成的，在这个实现过程中，如何取得事务处理场景中的 Connection对象，也是一个值得注意的地方。
|
||||
|
||||
|
||||
上面介绍了使用 DataSourceTransactionManager 实现事务创建、提交和回滚的过程，基本上与单独使用 Connection 实现事务处理是一样的，也是通过设置 autoCommit属性，调用 Connection 的 commit() 和 rollback()方法 来完成的。而我们在声明式事务处理中看到的那些事务处理属性，并不在 DataSourceTransactionManager 中完成，这和我们在前面分析中看到的是一致的。
|
||||
|
||||
|
||||
@ -23,11 +18,11 @@
|
||||
public class DataSourceTransactionManager extends AbstractPlatformTransactionManager
|
||||
implements ResourceTransactionManager, InitializingBean {
|
||||
|
||||
/** 这时注入的DataSource */
|
||||
/** 持有 javax.sql.DataSource对象 */
|
||||
private DataSource dataSource;
|
||||
|
||||
/**
|
||||
* 这里是产生Transaction的地方，为Transaction的创建提供服务，对数据库而言，
|
||||
* 这里是产生 Transaction对象 的地方，为 Transaction 的创建提供服务，对数据库而言，
|
||||
* 事务工作是由 Connection 来完成的。这里把数据库的 Connection对象 放到了 ConnectionHolder 中，
|
||||
* 然后封装到一个 DataSourceTransactionObject对象 中，在这个封装过程中增加了许多为事务处理服务的
|
||||
* 控制数据
|
||||
@ -54,8 +49,7 @@ public class DataSourceTransactionManager extends AbstractPlatformTransactionMan
|
||||
}
|
||||
|
||||
/**
|
||||
* 这里是处理事务开始的地方
|
||||
* 此实现设置隔离级别，但忽略超时
|
||||
* 这里是处理事务开始的地方，在这里设置隔离级别，但忽略超时
|
||||
*/
|
||||
@Override
|
||||
protected void doBegin(Object transaction, TransactionDefinition definition) {
|
||||
@ -143,8 +137,7 @@ public class DataSourceTransactionManager extends AbstractPlatformTransactionMan
|
||||
}
|
||||
}
|
||||
```
|
||||
上面介绍了使用DataSourceTransactionManager实现事务创建、提交和回滚的过程，基本上与单独使用Connection实现事务处理是一样的，也是通过设置autoCommit属性，调用Connection的commit()和rollback()方法来完成的。看到这里，大家一定会觉得非常的熟悉。而
|
||||
我们在声明式事务处理中看到的那些事务处理属性，并不在DataSourceTransactionManager中完成，这和我们在前面分析中看到的是一致的。
|
||||
上面介绍了使用 DataSourceTransactionManager 实现事务创建、提交和回滚的过程，基本上与单独使用 Connection 实现事务处理是一样的，也是通过设置 autoCommit属性，调用 Connection 的 commit() 和 rollback()方法 来完成的。看到这里，大家一定会觉得非常的熟悉。而我们在声明式事务处理中看到的那些事务处理属性，并不在 DataSourceTransactionManager 中完成，这和我们在前面分析中看到的是一致的。
|
||||
|
||||
## 3 小结
|
||||
总体来说，从声明式事务的整个实现中我们看到，声明式事务处理完全可以看成是一个具体的 Spring AOP应用。从这个角度来看，Spring事务处理 的实现本身就为应用开发者提供了一个非常优秀的 AOP应用 参考实例。在 Spring 的声明式事务处理中，采用了 IoC容器 的 Bean配置 为事务方法调用提供事务属性设置，从而为应用对事务处理的使用提供方便。
|
||||
@ -154,9 +147,9 @@ public class DataSourceTransactionManager extends AbstractPlatformTransactionMan
|
||||
- 如何读取事务处理属性值，在事务处理属性正确读取的基础上，结合事务处理代码，从而完成在既定的事务处理配置下，事务处理方法的实现。
|
||||
- 如何灵活地使用 Spring AOP框架，对事务处理进行封装，提供给应用即开即用的声明式事务处理功能。
|
||||
|
||||
在这个过程中，有几个Spring事务处理的核心类是我们需要关注的。其中包括TransactionInterceptor，它是使用AOP实现声明式事务处理的拦截器，封装了Spring对声明式事务处理实现的基本过程；还包括TransactionAttributeSource和TransactionAttribute这两个类，它们封装了对声明式事务处理属性的识别，以及信息的读入和配置。我们看到的TransactionAttribute对象，可以视为对事务处理属性的数据抽象，如果在使用声明式事务处理的时候，应用没有配置这些属性，Spring将为用户提供DefaultTransactionAttribute对象，该对象提供了默认的事务处理属性设置。
|
||||
在这个过程中，有几个 Spring事务处理 的核心类是我们需要关注的。其中包括 **TransactionInterceptor**，它是使用 AOP 实现声明式事务处理的拦截器，封装了 Spring 对声明式事务处理实现的基本过程；还包括 TransactionAttributeSource 和 **TransactionAttribute** 这两个类，它们封装了对声明式事务处理属性的识别，以及信息的读入和配置。我们看到的 TransactionAttribute对象，可以视为对事务处理属性的数据抽象，如果在使用声明式事务处理的时候，应用没有配置这些属性，Spring 将为用户提供 DefaultTransactionAttribute对象，该对象提供了默认的事务处理属性设置。
|
||||
|
||||
在事务处理过程中，可以看到TransactionInfo和TransactionStatus这两个对象，它们是存放事务处理信息的主要数据对象，它们通过与线程的绑定来实现事务的隔离性。具体来说，TransactionInfo对象本身就像是一个栈，对应着每一次事务方法的调用，它会保存每一次事务方法调用的事务处理信息。值得注意的是，在TransactionInfo对象中，它持有TransactionStatus对象，这个TransactionStatus是非常重要的。由这个TransactionStatus来掌管事务执行的详细信息，包括具体的事务对象、事务执行状态、事务设置状态等。
|
||||
在事务处理过程中，可以看到 **TransactionInfo** 和 **TransactionStatus** 这两个对象，它们是存放事务处理信息的主要数据对象，它们通过与线程的绑定来实现事务的隔离性。具体来说，TransactionInfo对象 本身就像是一个栈，对应着每一次事务方法的调用，它会保存每一次事务方法调用的事务处理信息。值得注意的是，在 TransactionInfo对象 中，它持有 TransactionStatus对象，这个 TransactionStatus 是非常重要的。由这个 TransactionStatus 来掌管事务执行的详细信息，包括具体的事务对象、事务执行状态、事务设置状态等。
|
||||
|
||||
在事务的创建、启动、提交和回滚的过程中，都需要与这个 TransactionStatus对象 中的数据打交道。在准备完这些与事务管理有关的数据之后，具体的事务处理是由 事务处理器TransactionManager 来完成的。在事务处理器完成事务处理的过程中，与具体事务处理器无关的操作都被封装到 AbstractPlatformTransactionManager 中实现了。这个抽象的事务处理器为不同的具体事务处理器提供了通用的事务处理模板，它封装了在事务处理过程中，与具体事务处理器无关的公共的事务处理部分。我们在具体的事务处理器(比如 DataSourceTransactionManager 和 HibernateTransactionManager)的实现中可以看到，最为底层的事务创建、挂起、提交、回滚操作。
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user