Spring如何保证事务获取到的是同一个Connection连接(Spring的事务同步机制)
Spring有声明式事务和编程式事务:
- 声明式事务只需要提供@Transactional的注解,然后事务的开启和提交/回滚、资源的清理就都由spring来管控,我们只需要关注业务代码即可;
- 编程式事务则需要使用spring提供的模板,如TransactionTemplate,或者直接使用底层的PlatformTransactionManager手动控制提交、回滚。
声明式事务的最大优点就是对代码的侵入性小,只需要在方法上加@Transactional的注解就可以实现事务;
编程式事务的最大优点就是事务的管控粒度较细,可以实现代码块级别的事务。
Spring把JDBC 的 Connection或者Hibernate的Session等访问数据库的链接(会话)都统一称为资源,显然我们知道Connection这种是线程不安全的,同一时刻是不能被多个线程共享的。
简单的说,同一时刻我们每个线程持有的Connection应该是独立的,且都是互不干扰和互不相同的
但是Spring管理的Service、Dao等,它们都是无状态的单例Bean,怎么破?,如何保证单例Bean里面使用的Connection都能够独立呢?
Spring引入了一个类:事务同步管理类org.springframework.transaction.support.TransactionSynchronizationManager来解决这个问题。它的做法是内部使用了很多的ThreadLocal为不同的事务线程提供了独立的资源副本,并同时维护这些事务的配置属性和运行状态信息 (比如强大的事务嵌套、传播属性和这个强相关)。
这个同步管理器TransactionSynchronizationManager是掌管这一切的大脑,它管理的TransactionSynchronization是开放给调用者一个非常重要的扩展点。
TransactionSynchronizationManager 将 Dao、Service 类中影响线程安全的所有 “ 状态 ” 都统一抽取到该类中,并用 ThreadLocal 进行封装,这样一来, Dao (基于模板类或资源获取工具类创建的 Dao )和 Service (采用 Spring 事务管理机制)就不用自己来保存一些事务状态了,从而就变成了线程安全的单例对象了。
DataSourceUtils
有些场景比如我们使用MyBatis的时候,某些场景下,可能无法使用 Spring 提供的模板类来达到效果,而是需要直接操作原生API Connection。
那如何拿到这个链接Connection呢??(这里有个大前提:必须保证和当前MaBatis线程使用的是同一个链接,这样才接受本事务控制)
DataSourceUtils就提供了这个能力:
public abstract class DataSourceUtils {
//...
public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException { ... }
//...
// 把definition和connection进行一些准备工作~
public static Integer prepareConnectionForTransaction(Connection con, @Nullable TransactionDefinition definition) throws SQLException { ...}
// Reset the given Connection after a transaction,
// con.setTransactionIsolation(previousIsolationLevel);和con.setReadOnly(false);等等
public static void resetConnectionAfterTransaction(Connection con, @Nullable Integer previousIsolationLevel) { ... }
// 该JDBC Connection 是否是当前事务内的链接~
public static boolean isConnectionTransactional(Connection con, @Nullable DataSource dataSource) { ... }
// Statement 给他设置超时时间 不传timeout表示不超时
public static void applyTransactionTimeout(Statement stmt, @Nullable DataSource dataSource) throws SQLException { ... }
public static void applyTimeout(Statement stmt, @Nullable DataSource dataSource, int timeout) throws SQLException { ... }
// 此处可能是归还给连接池,也有可能是close~(和连接池参数有关)
public static void releaseConnection(@Nullable Connection con, @Nullable DataSource dataSource) { ... }
public static void doReleaseConnection(@Nullable Connection con, @Nullable DataSource dataSource) throws SQLException { ... }
// 这个是真close
public static void doCloseConnection(Connection con, @Nullable DataSource dataSource) throws SQLException { ... }
// 如果链接是代理,会拿到最底层的connection
public static Connection getTargetConnection(Connection con) { ... }
}
getConnection()这个方法就是从TransactionSynchronizationManager里拿到一个现成的Connection(若没有现成的会用DataSource创建一个连接然后放进去),所以这个工具类还是蛮好用的。
其实Spring不仅为JDBC提供了这个工具类,还为Hibernate、JPA、JDO等都提供了类似的工具类。
org.springframework.orm.hibernate.SessionFactoryUtils.getSession()
org.springframework.orm.jpa.EntityManagerFactoryUtils.getTransactionalEntityManager()
org.springframework.orm.jdo.PersistenceManagerFactoryUtils.getPersistenceManager()
问题场景1模拟
// 此处省略关于DataSource、PlatformTransactionManager事务管理器等的配置
@Slf4j
@Service
public class HelloServiceImpl implements HelloService {
@Autowired
private JdbcTemplate jdbcTemplate;
@Transactional
@Override
public Object hello(Integer id) {
// 向数据库插入一条记录
String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
jdbcTemplate.update(sql);
// 做其余的事情 可能抛出异常
System.out.println(1 / 0);
return "service hello";
}
}
上面因为有事务,所以最终这个插入都是不会成功的。
@Transactional
@Override
public Object hello(Integer id) {
// 向数据库插入一条记录
String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
jdbcTemplate.update(sql);
// 根据id去查询获取 总数(若查询到了肯定是count=1)
String query = "select count(1) from user where id = " + id;
Integer count = jdbcTemplate.queryForObject(query, Integer.class);
log.info(count.toString());
return "service hello";
}
改造一下,count永远是返回1的。这应该也是我们面向过程编程时候的经典案例:前面insert一条记录,下面是可以立马去查询出来的
下面我们把它改造如下:
@Transactional
@Override
public Object hello(Integer id) {
// 向数据库插入一条记录
String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
jdbcTemplate.update(sql);
// 生产环境一般会把些操作交给线程池,此处我只是模拟一下效果而已~
new Thread(() -> {
String query = "select count(1) from user where id = " + id;
Integer count = jdbcTemplate.queryForObject(query, Integer.class);
log.info(count.toString());
}).start();
// 把问题放大
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "service hello";
}
经过这番改造,这样我们的count的值永远是0。
原因定位及解决方案
我们的异步线程的执行时,必须确保记录已经持久化到数据库了才可以。
在互联网环境编程中,我们经常为了提高吞吐量、程序性能,会使用到异步的方式进行优化、消峰等等。因此连接池、线程池被得到了大量的应用。我们知道异步的提供的好处不言而喻,能够尽最大可能的提升硬件的利用率和能力,但它带来的缺点只有一个:提升系统的复杂性,很多时候需要深入的了解它才能运用自如。
处理如下:
@Slf4j
@Service
public class HelloServiceImpl implements HelloService {
@Autowired
private JdbcTemplate jdbcTemplate;
@Transactional
@Override
public Object hello(Integer id) {
// 向数据库插入一条记录
String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
jdbcTemplate.update(sql);
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
// 在事务提交之后执行的代码块(方法) 此处使用TransactionSynchronizationAdapter,其实在Spring5后直接使用接口也很方便了~
@Override
public void afterCommit() {
new Thread(() -> {
String query = "select count(1) from user where id = " + id;
Integer count = jdbcTemplate.queryForObject(query, Integer.class);
log.info(count.toString());
}).start();
}
});
// 把问题放大
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "service hello";
}
}
我们使用TransactionSynchronizationManager注册一个TransactionSynchronization,然后在afterCommit里执行我们的后续代码,这样就能100%确保我们的后续逻辑是在当前事务被commit后才执行的。
它还有个方法afterCompletion()有类似的效果
TransactionSynchronizationManager
使用TreadLocal记录事务的一些属性,用于应用扩展同步器的使用,在事务的开启,挂起,提交等各个点上回调应用的逻辑。
// @since 02.06.2003 它是个抽象类,但是没有任何子类 因为它所有的方法都是静态的
public abstract class TransactionSynchronizationManager {
// ======保存着一大堆的ThreadLocal 这里就是它的核心存储======
// 应用代码随事务的声明周期绑定的对象 比如:DataSourceTransactionManager有这么做:
//TransactionSynchronizationManager.bindResource(obtainDataSource(), txObject.getConnectionHolder());
// TransactionSynchronizationManager.bindResource(obtainDataSource(), suspendedResources);
// 简单理解为当前线程的数据存储中心~~~~
private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");
// 使用的同步器,用于应用扩展
// TransactionSynchronization同步器是最为重要的一个扩展点~~~ 这里是个set 所以每个线程都可以注册N多个同步器
private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations = new NamedThreadLocal<>("Transaction synchronizations");
// 事务的名称
private static final ThreadLocal<String> currentTransactionName = new NamedThreadLocal<>("Current transaction name");
// 事务是否是只读
private static final ThreadLocal<Boolean> currentTransactionReadOnly = new NamedThreadLocal<>("Current transaction read-only status");
// 事务的隔离级别
private static final ThreadLocal<Integer> currentTransactionIsolationLevel = new NamedThreadLocal<>("Current transaction isolation level");
// 事务是否开启 actual:真实的
private static final ThreadLocal<Boolean> actualTransactionActive = new NamedThreadLocal<>("Actual transaction active");
// 返回的是个只读视图
public static Map<Object, Object> getResourceMap() {
Map<Object, Object> map = resources.get();
return (map != null ? Collections.unmodifiableMap(map) : Collections.emptyMap());
}
public static boolean hasResource(Object key) { ... }
public static Object getResource(Object key) { ... }
// actualKey:确定的key 拆包后的
@Nullable
private static Object doGetResource(Object actualKey) {
Map<Object, Object> map = resources.get();
if (map == null) {
return null;
}
Object value = map.get(actualKey);
// Transparently remove ResourceHolder that was marked as void...
// 如果ResourceHolder 被标记为了void空白了。此处直接从map里移除掉对应的key
// ~~~~~~~并且返回null~~~~~~~~~~~
if (value instanceof ResourceHolder && ((ResourceHolder) value).isVoid()) {
map.remove(actualKey);
// Remove entire ThreadLocal if empty...
if (map.isEmpty()) {
resources.remove();
}
value = null;
}
return value;
}
// 逻辑很简单,就是和当前线程绑定一个Map,并且处理ResourceHolder 如果isVoid就抛错
public static void bindResource(Object key, Object value) throws IllegalStateException {
Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
Assert.notNull(value, "Value must not be null");
Map<Object, Object> map = resources.get();
// set ThreadLocal Map if none found
if (map == null) {
map = new HashMap<>();
resources.set(map);
}
Object oldValue = map.put(actualKey, value);
// Transparently suppress a ResourceHolder that was marked as void...
if (oldValue instanceof ResourceHolder && ((ResourceHolder) oldValue).isVoid()) {
oldValue = null;
}
if (oldValue != null) {
throw new IllegalStateException("Already value [" + oldValue + "] for key [" +
actualKey + "] bound to thread [" + Thread.currentThread().getName() + "]");
}
}
public static Object unbindResource(Object key) throws IllegalStateException { ... }
public static Object unbindResourceIfPossible(Object key) { ... }
// 同步器是否是激活状态~~~ 若是激活状态就可以执行同步器里的相关回调方法了
public static boolean isSynchronizationActive() {
return (synchronizations.get() != null);
}
// 如果事务已经开启了,就不能再初始化同步器了 而是直接注册
public static void initSynchronization() throws IllegalStateException {
if (isSynchronizationActive()) {
throw new IllegalStateException("Cannot activate transaction synchronization - already active");
}
logger.trace("Initializing transaction synchronization");
synchronizations.set(new LinkedHashSet<>());
}
// 注册同步器TransactionSynchronization 这个非常重要 下面有详细介绍这个接口
// 注册的时候要求当前线程的事务已经是激活状态的 而不是随便就可以调用的哦~~~
public static void registerSynchronization(TransactionSynchronization synchronization) throws IllegalStateException {
Assert.notNull(synchronization, "TransactionSynchronization must not be null");
if (!isSynchronizationActive()) {
throw new IllegalStateException("Transaction synchronization is not active");
}
synchronizations.get().add(synchronization);
}
// 返回的是只读视图 并且,并且支持AnnotationAwareOrderComparator.sort(sortedSynchs); 这样排序~~
public static List<TransactionSynchronization> getSynchronizations() throws IllegalStateException { ... }
public static void clearSynchronization() throws IllegalStateException { ... }
//... // 省略name等其余几个属性的get/set方法 因为没有任何逻辑
// 这个方法列出来,应该下面会解释
public static void setActualTransactionActive(boolean active) {
actualTransactionActive.set(active ? Boolean.TRUE : null);
}
// 清楚所有和当前线程相关的(注意:此处只是clear清除,和当前线程的绑定而已~~~)
public static void clear() {
synchronizations.remove();
currentTransactionName.remove();
currentTransactionReadOnly.remove();
currentTransactionIsolationLevel.remove();
actualTransactionActive.remove();
}
}
这里把setActualTransactionActive单独拿出来看一下,以加深对事务执行过程的了解。
在AbstractPlatformTransactionManager.getTransaction()的时候会调用此方法如下:
TransactionSynchronizationManager.setActualTransactionActive(status.hasTransaction()); // 相当于表示事务为开启了
并且该类的handleExistingTransaction、prepareTransactionStatus等等方法都会此标记有调用,也就是说它会参与到事务的声明周期里面去。
以上方法他们统一的判断条件有:TransactionStatus.isNewTransaction()是新事务的时候才会调用这个方进行标记
另外此类它的suspend暂停的时候会直接的这么调用:
TransactionSynchronizationManager.setCurrentTransactionReadOnly(false);
TransactionSynchronizationManager.setActualTransactionActive(false);
resume恢复的时候:
TransactionSynchronizationManager.setCurrentTransactionReadOnly(resourcesHolder.readOnly);
TransactionSynchronizationManager.setActualTransactionActive(resourcesHolder.wasActive);
大体上可以得出这样的一个处理步骤:
- 开启新的事务时初始化。第一次开启事务分为:real首次 或 已存在事务但是REQUIRES_NEW
- 在事务的嵌套过程中,TransactionSynchronizationManager属性不断更新最终清除。即外层事务挂起;事务提交,这两个点需要更新TransactionSynchronizationManager属性。
- 这里面有个内部类AbstractPlatformTransactionManager.SuspendedResourcesHolder它是负责事务挂起时候,保存事物属性的对象,用于恢复外层事务。当恢复外层事务时,根据SuspendedResourcesHolder对象,调用底层事务框架恢复事务属性,并恢复TransactionSynchronizationManager
DefaultTransactionStatus
它实现了TransactionStatus接口。
这个是整个事务框架最重要的状态对象,它贯穿于事务拦截器,spring抽象框架和底层具体事务实现框架之间。
它的重要任务是在新建,挂起,提交事务的过程中保存对应事务的属性。在AbstractPlatformTransactionManager中,每个事物流程都会new创建这个对象。
TransactionSynchronizationUtils
主要是处理TransactionSynchronizationManager和执行TransactionSynchronization它对应的方法们。
TransactionSynchronization
这个类非常的重要,它是我们程序员对事务同步的扩展点:用于事务同步回调的接口,AbstractPlatformTransactionManager支持它。
注意:自定义的同步器可以通过实现Ordered接口来自己定制化顺序,若没实现接口就按照添加的顺序执行。
// @since 02.06.2003 实现了java.io.Flushable接口
public interface TransactionSynchronization extends Flushable {
int STATUS_COMMITTED = 0;
int STATUS_ROLLED_BACK = 1;
int STATUS_UNKNOWN = 2;
// 事务赞提suspend的时候调用此方法
// 实现这个方法的目的一般是释放掉绑定的resources
// TransactionSynchronizationManager#unbindResource
default void suspend() {
}
// 事务恢复时候调用
// TransactionSynchronizationManager#bindResource
default void resume() {
}
// 将基础会话刷新到数据存储区(如果适用) 比如Hibernate/Jpa的session
@Override
default void flush() {
}
// 在事务提交之前促发。在AbstractPlatformTransactionManager.processCommit方法里 commit之前触发
// 事务提交之前,比如flushing SQL statements to the database
// 请注意:若此处发生了异常,会导致回滚~
default void beforeCommit(boolean readOnly) {
}
// 在beforeCommit之后,在commit/rollback之前执行
// 它和beforeCommit还有个非常大的区别是:即使beforeCommit抛出异常了 这个也会执行
default void beforeCompletion() {
}
// 这个就非常重要了,它是事务提交(注意事务已经成功提交,数据库已经持久化完成这条数据了)后执行 注意此处是成功提交而没有异常
// javadoc说了:此处一般可以发短信或者email等操作~~因为事务已经成功提交了
// =====但是但是但是:======
// 事务虽然已经提交,但事务资源(链接connection)可能仍然是活动的和可访问的。
// 因此,此时触发的任何数据访问代码仍将“参与”原始事务 允许执行一些清理(不再执行提交操作!)
// 除非它明确声明它需要在单独的事务中运行。
default void afterCommit() {
}
// 和上面的区别在于:即使抛出异常回滚了 它也会执行的。它的notice同上
default void afterCompletion(int status) {
}
}
我们自定义一个同步器TransactionSynchronization使用得最多的是afterCommit和afterCompletion这两个方法,但是需要注意的是:
- 事务虽然已经提交,但是我的连接可能还是活动的(比如使用了连接池,连接是不会关闭的)
- 若你的回调中刚好又使用到了这个链接,它会参与到原始的事务里面去
- 这个时候你参与到了原始事务,但是它并不会给你commit提交。(所以你在这里做的update、insert等默认都将不好使)
- 回收资源(链接)的时候,因为你使用的就是原始事务的资源,所以Spring事务还会给你回收掉,从而就可能导致你的程序出错
为了加强理解,看看源码处是怎么个逻辑:
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
...
private void processCommit(DefaultTransactionStatus status) throws TransactionException {
...
try {
prepareForCommit(status);
triggerBeforeCommit(status);
triggerBeforeCompletion(status);
...
doCommit(status);
// 事务正常提交后 当然triggerAfterCompletion方法上面回滚里有而有个执行 此处不贴出了
try {
triggerAfterCommit(status);
} finally {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_COMMITTED);
}
} finally {
cleanupAfterCompletion(status);
}
}
...
// 清楚、回收事务相关的资源~~~ 并且恢复底层事务(若需要~)
private void cleanupAfterCompletion(DefaultTransactionStatus status) {
status.setCompleted();
if (status.isNewSynchronization()) {
TransactionSynchronizationManager.clear();
}
if (status.isNewTransaction()) {
doCleanupAfterCompletion(status.getTransaction());
}
if (status.getSuspendedResources() != null) {
if (status.isDebug()) {
logger.debug("Resuming suspended transaction after completion of inner transaction");
}
Object transaction = (status.hasTransaction() ? status.getTransaction() : null);
resume(transaction, (SuspendedResourcesHolder) status.getSuspendedResources());
}
}
}
从这个代码结构里可以看到,即使triggerAfterCommit和triggerAfterCompletion全部都执行了(哪怕是抛错了),最终它一定会做的是:cleanupAfterCompletion(status);这一步会回收资源。
那这种情况怎么避免被它回收呢?首先是可能,Spring建议使用一个新事务处理来避免这种可能性发生。
什么是新事务?比如上面的new了一个线程,那都别说新事务了,都开新线程,所以肯定是不存在此问题的。
Spring这里指的是若你还在同一个线程里,同步进行处理的时候,建议新启一个新事务(使用PROPAGATION_REQUIRES_NEW)
Spring是如何保证事务获取同一个Connection的
以JdbcTemplate为例。
JdbcTemplate执行SQL的方法主要分为update和query方法,它们的底层最终都是依赖于execute方法去执行(包括存储函数、储存过程),所以只需要看看execute是怎么获取connection链接的?
public class JdbcTemplate extends JdbcAccessor implements JdbcOperations {
...
public <T> T execute(StatementCallback<T> action) throws DataAccessException {
...
// dataSource就是此JdbcTemplate所关联的数据源,这个在config配置文件里早就配置好了
// 显然,这里获取的连接就是事务相关的,和当前想成绑定的connection
Connection con = DataSourceUtils.getConnection(obtainDataSource());
...
finally {
JdbcUtils.closeStatement(stmt);
DataSourceUtils.releaseConnection(con, getDataSource());
}
}
...
}
TransactionSynchronizationManager内部用ThreadLocal<Map<Object, Object>>对象存储资源,key为DataSource、value为connection对应的ConnectionHolder对象。
以上,就是它保证统一的核心原因。
TransactionSynchronization的实现类们
首先就是TransactionSynchronizationAdapter,从名称中就能看出它仅仅是个Adapter适配器而已,并不做实事。但是这个适配器额外帮我们实现了Ordered接口,所以子类们不用再显示实现了。
public abstract class TransactionSynchronizationAdapter implements TransactionSynchronization, Ordered {
@Override
public int getOrder() {
return Ordered.LOWEST_PRECEDENCE;
}
... // 省略空实现们~~~
}
其余实现均为内部类实现,比如DataSourceUtils.ConnectionSynchronization、SimpleTransactionScope.CleanupSynchronization。还有后面会碰到的一个相对重要的的内部类实现:ApplicationListenerMethodTransactionalAdapter.TransactionSynchronizationEventAdapter,它和事务监听机制有关。
问题场景2模型
场景一借助TransactionSynchronizationManager解决了“先插入再异步,异步线程查询不到”的问题,也就是:Spring如何在数据库事务提交成功后进行异步操作问题。
场景1最多就是丢失部分信息记录,影响甚微(毕竟非常重要的步骤并不建议使用这种异步方式去实现和处理)。
场景2也就是本场景最坏情况最终会导致Spring准备好的所有的connection都被close,从而以后再次请求的话拿到的都是已关闭的连接,最终可能导致整个服务的不可用,可谓非常严重。
其实如果你在afteCommit里面如果不直接直接使用connection连接,是不会出现连接被关闭问题的。因为现在的高级框架都很好的处理了这个问题
下面我模拟此场景的代码如下:
@Slf4j
@Service
public class HelloServiceImpl implements HelloService {
@Autowired
private JdbcTemplate jdbcTemplate;
@Transactional
@Override
public Object hello(Integer id) {
// 向数据库插入一条记录
String sql = "insert into user (id,name,age) values (" + id + ",'fsx',21)";
jdbcTemplate.update(sql);
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
// 在事务提交之后执行的代码块(方法) 此处使用TransactionSynchronizationAdapter,其实在Spring5后直接使用接口也很方便了~
@Override
public void afterCommit() {
String sql = "insert into user (id,name,age) values (" + (id + 1) + ",'fsx',21)";
int update = jdbcTemplate.update(sql);
log.info(update + "");
}
});
return "service hello";
}
}
预期结果:本以为第二个insert是插入不进去的(不是报错,而是持久化不了),但是最终结果是:两条记录都插入成功了。
与我之前掌握的理论相悖了,与Spring的javadoc里讲述的也相悖了(其实与Spring的并没有相悖,毕竟人家说的是“可能”)。这究竟咋回事呢?
afterCommit()内的connection也提交成功的原因分析
按照AbstractPlatformTransactionManager事务的源码执行处:
public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager, Serializable {
//...
private void processCommit(DefaultTransactionStatus status) throws TransactionException {
//...
try {
prepareForCommit(status);
triggerBeforeCommit(status);
triggerBeforeCompletion(status);
//...
doCommit(status);
// 事务正常提交后 当然triggerAfterCompletion方法上面回滚里有而有个执行 此处不贴出了
try {
triggerAfterCommit(status);
} finally {
triggerAfterCompletion(status, TransactionSynchronization.STATUS_COMMITTED);
}
} finally {
cleanupAfterCompletion(status);
}
}
//...
// 清楚、回收事务相关的资源~~~ 并且恢复底层事务(若需要~)
private void cleanupAfterCompletion(DefaultTransactionStatus status) {
status.setCompleted();
if (status.isNewSynchronization()) {
TransactionSynchronizationManager.clear();
}
if (status.isNewTransaction()) {
doCleanupAfterCompletion(status.getTransaction());
}
if (status.getSuspendedResources() != null) {
if (status.isDebug()) {
logger.debug("Resuming suspended transaction after completion of inner transaction");
}
Object transaction = (status.hasTransaction() ? status.getTransaction() : null);
resume(transaction, (SuspendedResourcesHolder) status.getSuspendedResources());
}
}
}
可以明确的看到执行到triggerAfterCommit/triggerAfterCompletion的时候doCommit是执行完成了的,也就是说这个时候事务肯定是已经提交成功了(此时去数据库里查看此记录也确定已经持久化)。
所以我猜测:后续该connection是不可能再执行connection.commit()方法了的,因为同一个事务只可能被提交一次。从上面理论知道:即使我们在afterCommit()里执行,Spring也保证了我拿到的连接还是当前线程所属事务的Connection。
因此我继续猜测:connection的自动提交功能可能是在这期间被恢复了,从而导致了这条SQL语句它的自动提交成功。
来到finally里cleanupAfterCompletion方法里有这么一句:
// 这里最终都会被执行~~~
// doCleanupAfterCompletion方法在本抽象类是一个空的protected方法
// 子类可以根据自己的需要,自己去实现事务提交完成后的操作
if (status.isNewTransaction()) {
doCleanupAfterCompletion(status.getTransaction());
}
我们大都使用的是子类DataSourceTransactionManager,本例也一样使用的是它。因此可以看看它对doCleanupAfterCompletion此方法的实现:
public class DataSourceTransactionManager extends AbstractPlatformTransactionManager
implements ResourceTransactionManager, InitializingBean {
//...
@Override
protected void doCleanupAfterCompletion(Object transaction) {
DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;
// 释放资源~~ Remove the connection holder from the thread, if exposed.
if (txObject.isNewConnectionHolder()) {
TransactionSynchronizationManager.unbindResource(obtainDataSource());
}
// Reset connection.
Connection con = txObject.getConnectionHolder().getConnection();
try {
// 这里是关键,在事后会恢复链接的自动提交本能,也就是常用的恢复现场机制嘛~~
// 显然这个和isMustRestoreAutoCommit属性的值有关,true就会恢复~~~
if (txObject.isMustRestoreAutoCommit()) {
con.setAutoCommit(true);
}
DataSourceUtils.resetConnectionAfterTransaction(con, txObject.getPreviousIsolationLevel());
}
//...
txObject.getConnectionHolder().clear();
}
//...
}
从上注释可知,现在问题的关键的就是DataSourceTransactionObject对象isMustRestoreAutoCommit的属性值了,若它是true,那就完全符合我的猜想。
DataSourceTransactionObject
关于DataSourceTransactionObject,它是一个DataSourceTransactionManager的一个私有内部静态类。
private static class DataSourceTransactionObject extends JdbcTransactionObjectSupport {
// 来自父类
@Nullable
private ConnectionHolder connectionHolder;
@Nullable
private Integer previousIsolationLevel;
private boolean savepointAllowed = false;
// 来自本类
private boolean newConnectionHolder;
private boolean mustRestoreAutoCommit; // 决定是否要恢复自动提交 默认情况下是false的
//...
public void setMustRestoreAutoCommit(boolean mustRestoreAutoCommit) {
this.mustRestoreAutoCommit = mustRestoreAutoCommit;
}
public boolean isMustRestoreAutoCommit() {
return this.mustRestoreAutoCommit;
}
}
这个内部类很简单,就是聚合了一些属性值,此处我们只关注mustRestoreAutoCommit这个属性值是否被设置为true了,若被设置过,就符合我的预期和猜想了。
通过代码跟踪,发现DataSourceTransactionManager在doBegin的时候调用了setMustRestoreAutoCommit方法如下:
@Override
protected void doBegin(Object transaction, TransactionDefinition definition) {
//...
if (con.getAutoCommit()) {
txObject.setMustRestoreAutoCommit(true); // 此处设置值为true
if (logger.isDebugEnabled()) {
logger.debug("Switching JDBC Connection [" + con + "] to manual commit");
}
con.setAutoCommit(false);
}
}
此处代码也就是当开启事务(doBegin)的时候的关键代码,它对DataSourceTransactionObject打入标记,表示最终需要事务返还给连接自动提交的能力。
场景2本想构造的是在afterCommit()里使用connection而最终被错误关闭的情况case,目前来看若使用的是DataSourceTransactionManager这个事务管理器的话,是不用担心这种情况发生的,最终你的SQL都会被成功提交,也不会出现被误close掉的问题~