a1k2l45k的博客

在Spring的开发中，我们常常会使用@Async来实现异步操作，而@Transactional则是用于事务管理的关键注解。然而，在它们的美妙联合中，有时也会潜藏着一些鲜为人知的坑。就像电影中的一对情侣，它们相互吸引，却也有相杀的时刻。让我们走进这场注解之恋，一探@Async与@Transactional的相爱相杀之谜。@Async 和 @Transactional 是 Spring Framework 中用于处理异步操作和事务管理的两个重要注解。

对于大批量数据库操作，使用手动事务提交可以很多程度上提高操作效率多线程对数据库进行操作时，并非线程数越多操作时间越快，按上述示例大约在2-5个线程时操作时间最快。对于多线程阻塞事务提交时，线程数量不能过多。来源 | https://blog.youkuaiyun.com/qq273766764/article/details/119972911@Autowired@Override//模拟总数据i < 10000;i++) {

②在xxxServiceImpl中，用(xxxService)(AopContext.currentProxy())，获取到xxxService的代理类，再调用事务方法，强行经过代理类，激活事务切面。但当同一个class中的方法A调用方法B时，会发现方法B中的异常不再导致回滚，也即事务失效了。而在同一个class中，方法A调用方法B，调用的是原对象的方法，而不通过代理对象。如果是在同一个类中的方法调用，则不会被方法拦截器拦截到，因此事务不会起作用，必须将方法放入另一个类，并且该类通过spring注入。

当事务消息发送成功后回掉RocketMQLocalTransactionListener#executeLocalTransaction方法，执行本地事务。第二次请求，因为流水id已经存在（报主键冲突异常），导致发送端扣钱失败，接收端也没收到消息，2边的钱都没发生变化，测试完成。还是以转账的demo演示一下，在db_account_1和db_account_2这2个库中，建立如下2张表。同时需要提供回查方法的实现，让rocketmq查询本地事务的执行状态，来决定是否投递消息。转账的时候先发送一条事务消息。

当Seata没有正常结束时，每个服务对应数据库中的undo_log表和seata持久化数据库的brach_table、global_table、lock_table、undo_log表都有可能有脏数据没有正确删除，从而导致服务一直回滚，却不成功。**解决办法:**清除undo_log表以及seata持久化数据库的brach_table、global_table、lock_table、undo_log表中的脏数据。那么可以分别在服务A、服务B、服务C的事务方法中添加。（2）每个服务中的XID不一致。

解决：先查看各服务的XID是否一致。

启动成功后，即可访问 http://127.0.0.1:7091/#/login 改地址进入seata的webui，用户名与密码默认为seata，可在上面的1.2章节中中提到的application.yml配置项：console.user中修改。在上述库中添加seata的配置表，sql文件存放在：seata/script/server/db/mysql.sql中。seata官网：http://seata.io/zh-cn/index.html。修改store.db配置项下的配置，连接到自己的数据库。

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel。