seata when doing global rollback ,may cause an endless loop

jei2mxaa  于 22天前  发布在  其他
关注(0)|答案(7)|浏览(15)
  • I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

if there is a table like
CREATE TABLE t_test ( urid int NOT NULL, name varchar(64) DEFAULT NULL, PRIMARY KEY ( urid ), UNIQUE KEY t_test_name ( name ) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
name is a uniquekey. and There is a piece of data in the table. (1,1)
1、global Transaction execute the sql "delete from t_test where id = 1", and this transaction need rollback
2、when rollbacking,other thread execute a sql like "insert into t_test values (2,1)"
3、that will cause the rollback thread endless loop.

Ⅱ. Describe what happened

that's because the range of the code "catch (SQLIntegrityConstraintViolationException e)" is too wide in AbstractUndoLogManager#undo
and rollback of business will be catched by this.
that should just catch "insertUndoLogWithGlobalFinished"

  • JDK version(e.g. java -version ):
  • Seata client/server version: 1.6.X
  • Database version: mysql 8.X
  • OS(e.g. uname -a ): centos7
  • Others: jdk8
mjqavswn

mjqavswn1#

If it is confirmed that it is not specially designed like this, I can mention pr to fix it.

0h4hbjxa

0h4hbjxa2#

When data needs to be restored to a state before deletion, and its unique index is being used by other rows, do you think this data is unrecoverable? Should such data be restored in an incomplete state?

mzmfm0qo

mzmfm0qo3#

It should be unrecoverable, at least from the point of view of seata. I think it can be treated as a dirty write operation, so that seata-server can keep the retry at a fixed frequency.

pwuypxnk

pwuypxnk4#

It should be unrecoverable, at least from the point of view of seata. I think it can be treated as a dirty write operation, so that seata-server can keep the retry at a fixed frequency.

I agree with this approach. In fact, it is unrecoverable.

piah890a

piah890a5#

It should be unrecoverable, at least from the point of view of seata. I think it can be treated as a dirty write operation, so that seata-server can keep the retry at a fixed frequency.

Then I'll mention a pr to fix it. Now this situation is an endless cycle because outside "for(;;)", and it should be possible to fix it.

t1rydlwq

t1rydlwq6#

@funky-eyes Please assign to me, I will fix it.

shstlldc

shstlldc7#

@funky-eyes Please assign to me, I will fix it.

ok

相关问题