Sharding-JDBC分布式事务总结（一）之本地事务（LOCAL）

sharding分布式事务之本地事务

1. 本地事务原理
   默认本地事务是在不开启任何分布式事务管理器的前提下，让每个数据节点各自管理自己的事务。 它们之间没有协调以及通信的能力，也并不互相知晓其他数据节点事务的成功与否。 本地事务在性能方面无任何损耗，但在强一致性以及最终一致性方面则力不从心。
   开启事务管理器后，shardingJDBC采取其实是一种弱XA事务，也是采用二阶段提交方式。
   事务管理器配置
   
   一条逻辑sql经过sharding解析后会生成多个数据连接，sharding将他们存放在一个map中。本地事务开始后就会一条一条逐一执行，如果sql执行失败或者是代码逻辑失败（1/0），就会逐一回滚。
   

commit时所有产生的数据连接逐一提交/回滚

 @Override
public void commit() throws SQLException {
    forceExecuteTemplate.execute(cachedConnections.values(), Connection::commit);
}

@Override
public void rollback() throws SQLException {
    forceExecuteTemplate.execute(cachedConnections.values(), Connection::rollback);
}

为啥是弱XA事务呢？我的理解是在事务二阶段提交时，sharding没有对报错处理，forceExecuteTemplate.execute方法源码如下：

public void execute(final Collection<T> targets, final ForceExecuteCallback<T> callback) throws SQLException {
    Collection<SQLException> exceptions = new LinkedList<>();
    for (T each : targets) {
        try {
            callback.execute(each);
        } catch (final SQLException ex) {
            exceptions.add(ex);
        }
    }
    throwSQLExceptionIfNecessary(exceptions);
}

可以看到在二阶段提交过程中对于抛错只是进行catch处理，所以对于服务器宕机或者是网络原因引起的提交失败，本地事务无法处理，可以看到官网介绍：

本地事务的开启仅需加注解 @Transactional即可（开启弱XA事务需要配置事务管理器），@ShardingTransaction(TransactionType.LOCAL)是选择sharding的分布式事务类型，此注解不添加的化会默认使用本地事务。

顺便说一句，在我整合的项目中，用@ShardingTransaction(TransactionType.BASE)进行事务切换并没有生效，在后续我会给出可能的原因以及解决办法。