ShardingJdbc2.X学习总结系列（十一）：源码解析—事务

事务：恢复和并发控制的基本单位。具有ACID（原子性、一致性、隔离性、持久性）四大属性。

数据库事务：可以是一条sql或者一组sql的执行，当事务包含多条sql时，有一个执行出现异常，就会全部回滚。

但是ShardingJdbc是主要应用在分库分表上，当这个时候在加上事务的话，就会使事务变得很复杂。

ShardingJdbc默认是没有事务的，如果配置了事务也是弱事务，我们看一下官方文档对于弱事务的介绍

1.完全支持非跨库事务，例如：仅分表，或分库但是路由的结果在单库中

2.完全支持因逻辑异常导致的跨库事务。例如：同一事务中，跨两个库更新。更新完毕后，抛出空指针，则两个库的内容都能回滚

3.不支持因网络、硬件异常导致的跨库事务。例如：同一事务中，跨两个库更新，更新完毕后、未提交之前，第一个库死机，则只有第二个库数据提交

public final void commit() throws SQLException {
        Collection<SQLException> exceptions = new LinkedList<>();
        for (Connection each : cachedConnections.values()) {
            try {
                each.commit();
            } catch (final SQLException ex) {
                exceptions.add(ex);
            }
        }
        throwSQLExceptionIfNecessary(exceptions);
    }

我们可以看到这里事务的提交，其实是每一个连接的提交，多个连接互相不影响，这样的话可能会导致数据一致性的问题，

ShardingJdbc针对于上面的问题实现了柔性事务（最大努力型事务），在使用的时候我们是需要引入 transaction jar包的

<dependency>
            <groupId>io.shardingjdbc</groupId>
            <artifactId>sharding-jdbc-transaction</artifactId>
            <version>2.0.3</version>
        </dependency>

上面这张图是官网的图

我在SQL执行的那一篇中介绍过，在SQL执行前，执行成功和执行失败的时候，都会通过EVENTBUS进行事件的推送

这里主要就是对上面的这3个事件进行处理

1.执行前记录日志

2.执行成功删除日志

3.执行失败，重试一定次数（重试成功，依然删除日志）

由于失败采用的是重试机制，也就是说一条SQL可能会被执行多次，所以执行的SQL必须要满足幂等，所以官方提到了适用场景

1.根据主键删除数据

2.更新记录永久状态，如更新通知送达状态

所以幂等性的要求就是必须满足一下几点

1.INSERT语句要求必须包含主键，且不能是自增主键

2.UPDATE语句要求幂等，不能是UPDATE xxx SET x=x+1

核心源码分析

我们知道事件是通过eventBus进行发布的，那也就是注册监听事件的地方处理，我们看到在代码中调用

EventBusInstance.getInstance().register(new BestEffortsDeliveryListener())的地方是在SoftTransactionManager的init方法。

public void init() throws SQLException {
        ① EventBusInstance.getInstance().register(new BestEffortsDeliveryListener());
        if (TransactionLogDataSourceType.RDB == transactionConfig.getStorageType()) {
            Preconditions.checkNotNull(transactionConfig.getTransactionLogDataSource());
            ② createTable();
        }
        if (transactionConfig.getBestEffortsDeliveryJobConfiguration().isPresent()) {