sharding分布式事务之本地事务
- 本地事务原理
默认本地事务是在不开启任何分布式事务管理器的前提下,让每个数据节点各自管理自己的事务。 它们之间没有协调以及通信的能力,也并不互相知晓其他数据节点事务的成功与否。 本地事务在性能方面无任何损耗,但在强一致性以及最终一致性方面则力不从心。
开启事务管理器后,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)进行事务切换并没有生效,在后续我会给出可能的原因以及解决办法。