@fengpan567 不是每次，不频繁。比如这次，由原先的实时导出改为做成一个导出中心，通过用户下载的方式实现。
改动就是把每次请求返回导出的 excel ，切换为导出推送到 oss ，并产生一个推送记录，用户通过推送记录获取 oss 的 url 来下载

@c3de3f21 是的，有 DevOps

@dayeye2006199 是个思路

@ZZ74 说明什么，我从头到尾写的多线程，本来就是多事务

@ZZ74 实际操作下应该就可以明白了，可能我的表述有问题，但是结果就是我说的那样，多个线程操作并且事务手动情况下，更新同一条数据就是会陷入无限的锁等待，可能我说死锁说法有问题
https://i.imgur.com/viH1rFz.png
https://i.imgur.com/HKK4wbP.png

多线程操作适合用于查询、插入、删除，可能不适合更新。
更新操作数据库会自动上行锁，假如两个任务操作了同一行数据。

任务一拿到行锁-完成任务-等待任务二完成一起 commit 并释放锁，
任务二等待行锁占用者释放行锁，它得拿到锁才能进行更新。

所以任务一 一直等待事务提交释放行锁
任务二一直处于行锁等待状态。
这就是一个死锁状态。

@ZZ74
@ppto 多线程操作适合用于查询、插入、删除，可能不适合更新。
更新操作数据库会自动上行锁，假如两个任务操作了同一行数据。
任务一拿到行锁-完成任务-等待任务二完成一起 commit 并释放锁，
任务二等待行锁占用者释放行锁，它得拿到锁才能进行更新，
所以任务一一直等待事务提交释放行锁任务二一直处于行锁等待

@BQsummer https://developer.aliyun.com/article/1203834
这种方式的确是可行的，它实实在在的解决了事务的提交回滚在各个子线程处理的问题，但是，它也有自己的局限性，
```sqlSession.getMapper() ```问题就在这行代码，就是说只有通过这个方法获取的 Mapper 才能进行事务控制，通过 spring 周期管理的 Mapper 还是不受这个事务控制的，这个方法获取的 Mapper 是通过代理又创建了一个新的实例。

那么它的实现逻辑也就不能实现我的诉求，我希望是这个多线程工具对业务代码没有侵入性，也就是业务代码只要实现一个 Runnable 或者 Callable 就可以直接使用，这个显然需要对业务代码进行改动的

@monmon 老项目升级 jdk 比较困难

@jli100 差不多，能看得清晰一点

@ZZ74 当然有关系，所有任务跑完 commit ，线程池只有 10 个线程一次只能执行 10 个任务怎么全跑完，10 个任务执行完了是 commit 还是 rollback ，后边还有任务呢

@BQsummer 好的，忘记还有这种方式了

好，我研究下，忘记还有这种方式了

找到个办法，完整代码
https://i.imgur.com/SzGG2qC.png

@ppto 对的，我这个实现的思路就是来自 seata ，阿里的那个分布式事务服务。

@BuffDog 多个事务，只是需要协同控制一起提交和回滚

@MakHoCheung 问题不是因为耗时吗，需要节省时间就需要多线程。多线程就得多事务

@BQsummer 是滴，目前我的观点看，二阶段提交无解

贴点代码看看
https://imgur.com/ElOAPtp