spring事务管理器设计思想

在最近做的一个项目里面，涉及到多数据源的操作，比较特殊的是，这多个数据库的表结构完全相同，由于我们使用的ibatis框架作为持久化层，为了防止每一个数据源都配置一套规则，所以重新实现了数据源，根据线程变量中指定的数据库连接名称来获取实际的数据源。

一个简单的实现如下：

public class ProxyDataSource implements DataSource {
/** 数据源池配置 */
private Map<String, DataSource> dataSourcePoolConfig;

public Connection getConnection() throws SQLException {
        return createDataSource().getConnection();
}
private synchronized DataSource createDataSource() {
        String dbName = DataSourceContextHolder.getDbName();
        return dataSourcePoolConfig.get(dbName);
}

 

每次调用spring事务管理器之前，设置DataSourceContextHolder.set(“dbName”) 

事务提交之后在调用 DataSourceContextHolder.clear() 方法即可

 但是这样设计实际使用过程中也会遇到一些典型的问题，这就是在仔细了解spring中持久化层的设计之后，才能明白所产生的问题的原因。下面主要总结一下spring 持久化的设计。

 

Jdbc基本的编程模型

由于任何持久化层的封装实际上都是对java.sql.Connection等相关对象的操作，一个典型的数据操作的流程如下：

但在我们实际使用spring和ibatis的时候，都没有感觉到上面的流程，其实spring已经对外已经屏蔽了上述的操作，让我们更关注业务逻辑功能，但是我们有必要了解其实现，以便能够更好运用和定位问题。

 

开启事务：

在开启事务的时候，我们需要初始化事务上下文信息，以便在业务完成之后，需要知道事务的状态，以便进行后续的处理，这个上下文信息可以保存在 ThreadLocal里面，包括是否已经开启事务，事务的超时时间，隔离级别，传播级别，是否设置为回滚。这个信息对应用来说是透明的，但是提供给使用者编程接口，以便告知业务结束的时候是提交事务还是回滚事务。

 

获取连接

首先来看看spring如何获取数据库连接的，对于正常情况来看，获取连接直接调用DataSource.getConnection()就可以了，我们在自己实现的时候也肯定会这么做，但是需要考虑两种情况（这里面先不引入事务的传播属性）：

1 还没有获取过连接，这是第一次获取连接

2 已经获取过连接，不是第一次获取连接，可以复用连接

解决获取数据库连接的关键问题就是如何判断是否已经可用的连接，而不需要开启新的数据库连接，同时由于数据库连接需要给后续的业务操作复用，如何保持这个连接，并且透明的传递给后续流程。对于一个简单的实现就是使用线程上下文变量ThrealLocal来解决以上两个问题。

具体的实现是：在获取数据库连接的时候，判断当前线程线程变量里面是否已经存在相关连接，如果不存在，就创新一个新的连接，如果存在，就直接获取其对应的连接。在第一次获取到数据库连接的时候，我们还需要做一些特殊处理，就是设置自动提交为false。在业务活动结束的时候在进行提交或者回滚。这个时候就是要调用connection.setAutoCommit(false)方法。

 

执行sql

这一部分和业务逻辑相关，通过对外提供一些编程接口，可以让业务决定业务完成之后如何处理事务，比较简单的就是设置事务状态。

 

提交事务：

在开启事务的时候，事务上下文信息已经保存在线程变量里面了，可以根据事务上下文的信息，来决定是否是提交还是回滚。其实就是调用数据库连接Connection.commit 和 Connection.rollback 方法。然后需要清空线程变量中的事务上下文信息。相当于结束了当前的事务。

  

关闭连接：

关闭连接相对比较简单，由于当前线程变量保存了连接信息，只需要获取连接之后，调用connection.close方法即可，接着清空线程变量的数据库连接信息。

 上面几个流程是一个简单的事务处理流程，在spring中都有对应的实现，见TransactionTemplate.execute方法。Spring定义了一个TransactionSynchronizationManager对象，里面保存了各种线程变量信息，

 

//保存了数据源和其对应连接的映射，value是一个Map结构，其中key为datasource，value为其打开的连接

private static final ThreadLocal resources

//这个暂时用不到，不解释

private static final ThreadLocal synchronizations

//当前事务的名字

private static final ThreadLocal currentTransactionName

//是否是只读事务以及事务的隔离级别（这个一般我们都用不到，都是默认界别）

private static final ThreadLocal currentTransactionReadOnly

private static final ThreadLocal currentTransactionIsolationLevel

//代表是否是一个实际的事务活动，这个后面将）

private static final ThreadLocal actualTransactionActive

 

在获取连接的时候，可见DataSourceUtils.doGetConnection()方法，就是从调用TransactionSynchronizationManager.getResource(dataSource)获取连接信息，如果为空，就直接从调用dataSource.getConnection()创建新的连接，后面在调用

TransactionSynchronizationManager.bindResource(dataSource,conn)绑定数据源到线程变量，以便后续的线程在使用。

ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);

                   if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {

                            conHolder.requested();

                            if (!conHolder.hasConnection()) {

                                     logger.debug("Fetching resumed JDBC Connection from DataSource");

                                     conHolder.setConnection(dataSource.getConnection());

                            }

                            return conHolder.getConnection();

                   }

        

                   logger.debug("Fetching JDBC Connection from DataSource");

                   Connection con = dataSource.getConnection();

在提交事务的时候，见 DataSourceTransactionManager.doCommit方法，其实就是获取事务状态信息以及连接信息，调用conn.commmit方法，比较简单。

 

但是实际上，spring事务管理远远比上述复杂，我们没有考虑以下几种情况：

1 如果当前操作不需要事务支持，也就是每次执行一次，就自动进行提交。如何在同一个架构里面兼容这两种情况。比如就是简单的query操作。

2 一个业务活动跨越多个事务，每个事务的传播级别配置不一样。后面会拿一个例子来说明

 

对于第一个问题，比较好解决，首先就是根据线程变量里面获取数据源对应的连接，如果有连接，就复用。如果没有，就创建连接。在判断当前是否存在活动的事务上下文，如果存在事务信息，设置conn.setAutoCommit(false),然后设置线程上下文，绑定对应的数据源。如果不存在事务信息，就直接返回连接给应用。

这样就会带来一个新的问题，就是连接如何进行关闭。根据最开始的分析，在存在事务上下文的情况下，直接从获取线程获取对应的数据库连接，然后关闭。在关闭的也需要也进行判断一下即可。在spring里面，在事务中获取连接和关闭连接有一些特殊的处理，主要还是和其jdbc以及orm框架设计兼容。在jdbcTemplate,IbatiTemplate每执行一次sql操作，就需要获取conn，执行sql，关闭conn。如果不存在事务上下文，这样做没有任何问题，获取一次连接，使用完成，然后就是比。但是如果存在事务上下文，每次获取的conn并不一定是真实的物理连接，所以关闭的时候，也不能直接关闭这数据库连接。Spring的中定义一个ConnectionHandle对象，这个对象持有一个数据库连接对象，以及该连接上的引用次数(retain属性)。每次复用一次就retain++ 操作，没关闭一次，就执行retain-- 操作，在retain 为0的时候，说明没有任何连接，就可以进行真实的关闭了。

对于第二个问题，涉及到事务的传播级别，定义如下：

PROPAGATION_REQUIRED-- 如果当前没有事务，就新建一个事务。这是最常见的选择。 
PROPAGATION_SUPPORTS-- 如果当前没有事务，就以非事务方式执行。 
PROPAGATION_MANDATORY-- 如果当前没有事务，就抛出异常。 
PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。 
PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 
PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。 

 

在开启事务之前，正常情况下需要做两个事情

一：获取当前事务上下文信息

二：获取将要开启事务的传播属性

根据以上两个信息，来判断程序的处理方式，具体方式如下：

而处理流程则是如下：

其中上图标中英文简称对应的事务传播属性如下：

RE：               PROPAGATION_REQUIRED-- 如果当前没有事务，就新建一个事务。这是最常见的选择。 

SPT                PROPAGATION_SUPPORTS-- 如果当前没有事务，就以非事务方式执行。 
MA：              PROPAGATION_MANDATORY-- 如果当前没有事务，就抛出异常。 
RE_NEW：      PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。 
NOT_SPT:      PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 
NEVER:          PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。 

通过上面发现，只有新创建资源的时候，才会开启事务，在其他的情况下，只需要返回事务状态信息就可以了。其实这个状态信息，就是事务的上下文信息。

 

事务上下文

通过上面的分析，每次启动事务的时候，都会判断当前是否存在事务，要么抛出异常，否则都会创新事务上下文，但是对于数据源的处理方式则是不一样的，这个要根据当前事务传播属性和新的事务传播属性共同决定。

事务上下文信息到底是什么，这个完全是可以自定义的，在spring中，主要是表现为TransactionStatus，也就是事务状态信息。里面保存了事务相关的信息，

//事务对象信息，使用普通数据源的话，是DataSourceTransactionObject对象，保存//了事务对应的连接信息

private final Object transaction;

//是否是新开启的事务信息，只有调用了开启事务的方法，这个才为true

private final boolean newTransaction;

//这个是事务同步器，不是事务要关心的，spring在事务提交之前或者之后座的hook

private final boolean newSynchronization;

//是否是只读事务

private final boolean readOnly;

//日志debug信息，完全没有放在这里

private final boolean debug;

//挂起的事务信息，如果没有，则为空

private final Object suspendedResources;

 

通过事务状态信息，就可以完全知道当前事务的所有信息，包括事务的对应的数据源连接信息，是否是新创建的事务，是否是只读事务，以及之前挂起的事务信息。这些对事务管理器起来说，都是必须的信息。但是个人觉得也存在一些问题，首先spring这个事务状态信息有两个使用者，一个是spring本身事务管理器使用，另外一个是应用程序接口。对应用程序接口暴露出来的状态信息以及内部使用的事务上下文信息应该隔离出来，避免应用程序人为的修改了事务上下文的属性信息。当然，可以用过接口的方式进行避免，但是如果知道实现原理的话，完全可以通过强制转化为实现对象，从而破坏事务其他的信息导致程序异常。当然，正常情况下不太可能有人会如此无聊。 

 从上面的分析来看，spring的事务管理器（这里都特指DataSourceTransactionManager）主要的工作流程就是创建事务信息，绑定数据源，获取数据库连接，提交活回滚事务，释放数据库连接，解绑数据源。其实整个事务管理器做的事情无非就是这些。让应用者更关注业务逻辑，而不是复杂的事务管理。

 DataSourceTransactionManager事务管理器本身实现了ResouceManager的功能，就是返回对应的其注册的datasrouce。这是一种一对一的映射关系，也就是说一个事务管理器只能注册一个数据源，不支持多数据源的管理。一旦事务管理器开启事务，就和具体的数据源绑定了，你只能通过其对应的数据源获取数据库连接。所以在事务上下文里面操作多个数据库，是不可能的。同时也只支持单一物理数据源，也就是说一个数据源只能返回同一个数据库连接，不支持在同一个事务里面通过同一个逻辑数据源跨越多个物理库操作。下面的操作想通过ProxyDataSource切换实际的数据源的方式无法实现的。

 

for(String dbName : dbNames){

             DataSourceContextHolder.set(“dbName”);

             doSomeThing();

            DataSourceContextHolder.clear();

}

 

想要支持跨库的事务操作，可以通过以下几种方式操作：

1 使用JtaTransactionManager，通过jta服务提供商来实现跨库事务

2 改写ProxyDataSource，通过返回其自己实现的Connection来实现跨库的事务。简单的说，返回一个逻辑的Connection，这个connection本身持有多个物理connection

3 自己实现TransactionManager，可以注册多个资源管理器，自己对多个数据源进行管理。

 

事务上下文的扩展

正常情通过况下，事务上下文信息都是保存在内存之中，相当于只能够支持单个jvm。可以想象一下，假设事务管理器把事务上下文信息持久化，并且通过远程调用的方式，把事务上下文信息传递给另外一个jvm，通过这样的设计思想，可以支持跨jvm间的事务一致性，也就是我们所说的分布式系统的事务。当然，这只是一中简单的想法，具体的实现会相当复杂，需要考虑点也有很多。