责任链的事务回滚要怎么实现？

Question

问题描述

我有一个复杂的业务流，这个业务流会对多个业务模块的数据造成影响，我打算通过责任链的设计模式来解决一个“大方法”写全部功能的问题。

但是这里面会涉及到一个回滚问题，如果这个责任链中的任意一个操作失败了，应当对之前的数据进行一个回滚。但如果这个时候数据库连接池挂了，或者是网络断了，或者服务器停电了，我应该怎么把事务给回滚呢？

问题出现的环境背景及自己尝试过哪些方法

我想的办法比较蠢：

1. 整个责任链使用同一个事务，直到最后一次提交，才提交整个事务。
2. 把整个责任链需要提交数据的部分独立出来，最后单独写一个实现用于统一的事务提交。

方法1的缺点是如果责任链太冗长，这个事务时间过长很可能会导致数据库发生死锁的情况，并且这种代码不加以注意，后续维护一不小心就容易出现问题
方法2的缺点是每个实现类所需要提交的数据不一样，不太好去封装。

你期待的结果是什么？实际看到的错误信息又是什么？

求一点建议，多谢多谢

Answer 1

说下自己的总结，因为各自的场景可能不同，仅供参考。

大概理解下题主的意思是，让所有责任链中对数据的修改，要实现最后统一提交或者回滚的方案。并提出了两个方法。

在这个既定场景中，个人倾向方法2，可以把每个节点的数据操作，转化为sql语句，这个方式挺多的。然后用一个全局变量或ThreadLocal保存每个节点的sql，在最后使用事务一次性提交。

但就个人经验说下，责任链是一种提高流程扩展性的设计模式。所以应用中每个节点只有顺序关联，而没有数据关联，这样才能发挥它的作用，可以方便扩展。
即每个节点都可以用单独的事务，只保证本节点的数据正确性，处理之后，根据情况判断是否向下传递或向上驳回。

如果题主的数据是要求全部提交或回滚的，可能并不适合拆分成多个节点。

Answer 2

我觉得方法2才不好维护吧，责任链的优势就是维护节点，只需要添加或者删除即可。我的建议，抽象出一种节点，这种节点一定会操作数据库，对链表排序，记录有多少个操作数据库节点，以索引为主要，节点类型为次要。这样尽可能的把操作数据库的节点集中，当所有数据库节点完成的时候，提交事务。让事务时间尽可能短。其实你担心数据库阻塞不太可能会发生，除非你事务隔离级别设置为串行化或者特别高，或者表锁概念，阻塞的概率才会变大，另外，死锁这个是持锁抢锁问题，和你的场景无关吧。