多线程并发使用seata的问题

[xbox1994]

子线程使用RootContext.bind(xid);绑定了主线程的xid，能让报错时整体回滚。但碰到一个问题：

第一个线程修改一个字段，将数据从A改到B，第二个线程修改相同字段（因为是相同xid，可以获取到全局锁），将数据从B改到C，业务异常回滚，那么第一个线程会回滚失败，因为发现脏数据，此时全局锁就一直不会被释放，数据一直被锁住，业务无法继续下去。

请问下官方大佬，这种场景，除了在业务上避免并发修改相同数据外，还有什么好的解决方案呢？seata有机制可以避免吗？或者是我们用seata的方式不对？

[funky-eyes]

What version are you using?

[xbox1994]

What version are you using?

1.7.0

[funky-eyes]

请给我看一下你的branch table的表结构
Please show me the table structure of your branch table

[xbox1994]

请给我看一下你的branch table的表结构 Please show me the table structure of your branch table

https://github.com/apache/incubator-seata/blob/1.7.0/script/server/db/mysql.sql

与官方结构一样

[funky-eyes]

请给我看一下你的branch table的表结构 Please show me the table structure of your branch table

https://github.com/apache/incubator-seata/blob/1.7.0/script/server/db/mysql.sql

与官方结构一样

把你的结构截图或者导出来，空口无凭
Screenshot or export your structure

[xbox1994]

不同线程在同一个事务内修改相同数据：

第一个分支回滚失败：

还查了数据库的binlog，05-11期间只有这两次update：

[funky-eyes]

请给我看一下你的branch table的表结构 Please show me the table structure of your branch table

https://github.com/apache/incubator-seata/blob/1.7.0/script/server/db/mysql.sql
与官方结构一样

把你的结构截图或者导出来，空口无凭 Screenshot or export your structure

talk me branch table structure ok？

[xbox1994]

sorry for wrong table, this is branch table

CREATE TABLE branch_table (
branch_id bigint(20) NOT NULL,
xid varchar(128) NOT NULL,
transaction_id bigint(20) DEFAULT NULL,
resource_group_id varchar(32) DEFAULT NULL,
resource_id varchar(256) DEFAULT NULL,
branch_type varchar(8) DEFAULT NULL,
status tinyint(4) DEFAULT NULL,
client_id varchar(64) DEFAULT NULL,
application_data varchar(2000) DEFAULT NULL,
gmt_create datetime(6) DEFAULT NULL,
gmt_modified datetime(6) DEFAULT NULL,
PRIMARY KEY (branch_id),
KEY idx_xid (xid)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

[funky-eyes]

如果你的server用的是1.7，并且gmt_create的精度为6，没有相同资源重入后因为回滚顺序不对导致的脏写问题。
If your server is using 1.7 and gmt_create has a precision of 6, there is no problem with dirty writes due to rollbacks in the wrong order after reentry of the same resource.

[13333713052]

如果你的server用的是1.7，并且gmt_create的精度为6，没有相同资源重入后因为回滚顺序不对导致的脏写问题。 If your server is using 1.7 and gmt_create has a precision of 6, there is no problem with dirty writes due to rollbacks in the wrong order after reentry of the same resource.

我按照他这个使用了2.0版本的seata server和SDK，gmt_create精度也是6，同一数据连续修改两次，抛出异常后，回滚也遇到了这个问题

[funky-eyes]

如果你的server用的是1.7，并且gmt_create的精度为6，没有相同资源重入后因为回滚顺序不对导致的脏写问题。 If your server is using 1.7 and gmt_create has a precision of 6, there is no problem with dirty writes due to rollbacks in the wrong order after reentry of the same resource.

我按照他这个使用了2.0版本的seata server和SDK，gmt_create精度也是6，同一数据连续修改两次，抛出异常后，回滚也遇到了这个问题

自行官网查看升级手册的说明
Check the instructions of the upgrade manual on your own official website.

[xbox1994]

不知道咋说，用了官方的例子，加了并发的代码，百分百复现

[xbox1994]

如果你的server用的是1.7，并且gmt_create的精度为6，没有相同资源重入后因为回滚顺序不对导致的脏写问题。 If your server is using 1.7 and gmt_create has a precision of 6, there is no problem with dirty writes due to rollbacks in the wrong order after reentry of the same resource.

有没有可能回滚顺序是对的，但是正要回滚时的数据被其他线程修改了，就是其他线程没来得及停下来修改数据

[funky-eyes]

不知道咋说，用了官方的例子，加了并发的代码，百分百复现

把你的日志全部贴上来,server侧的