遇到了一个诡异的 bug，接口超时重试导致前后两次的事务被合并起来一起提交了

[kvkboy]

场景: web 向后台发起一个比如添加用户的请求，这个接口是插入一条用户数据和一条角色关联数据（假设这里的角色是唯一的，一个角色只能被一个用户关联）。

第一次调用超时，第二次重试的调用成功，但是发现数据库有两条一模一样的数据，包括唯一的角色

我在业务代码里校验了角色是否存在(不要问我为啥没用唯一键，为了模拟场景)，但是发现并没触发

看了下数据，两个 user 数据的插入时间是大概相差 20s，但关联表的 role 数据的插入时间反而是一样，非常疑惑

我怀疑第一次的时候调用还没失败但等待的时候导致超时，然后第二次重试才会略过我的代码校验，然后因为事务传播的默认设置，导致用了前一次的事务，最后两条数据一起被提交。

propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。

[kvkboy]

我定位不到原因，但是数据的时间这个差异确实存在让我非常疑惑，我只能这么怀疑是不是事务传播的锅

[kvkboy]

先插入 user，后插入 role，user 之间存在 20s 的时间差，但是两条 role 数据的创建时间和第二次重试的一模一样。

[fixU]

看看数据库隔离级别，如果是 rr，那么在第一次请求未提交事务之前，第二条请求进来的话，这个(角色是否存在)的校验是不会成立的

[fixU]

这个业务场景可以考虑下 @Transaction(isolation = Isolation.RC)

[takemeaway]

SQL 都不贴，谁知道呢。

[kvkboy]

@takemeaway 这贴啥 SQL 就是单纯的 mybatis 的两条插入语句

[kvkboy]

@fixU 我就是有一个疑问，第一次的请求可能某种原因数据库慢了点导致超时，那这时候这个事务还会不会继续执行，导致第二次重试的请求进来的时候是复用了第一次的事务而不是新开的一个事务

[kvkboy]

@fixU 嗯，你是对的，应该没那么复杂，就是当时数据库可能因为某种原因导致卡了，第一次的事务未提交，第二次直接是通过了业务校验，最后数据库恢复了，两个事务都提交了，才会有时间差，可能是我想复杂了

[momocraft]

超时是在哪里超时的，客户端 / gateway / 真正连接数据库的服务器？

[kvkboy]

@momocraft
是真正连接数据库的服务器，接口执行 insert 的时候太久导致接口超时

[yqsas]

重试用的什么方式做的

[kvkboy]

@yqsas dubbo 的接口重试