when doing global rollback ,may cause an endless loop

[sixlei]

• 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 TABLEt_test(uridint 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

[sixlei]

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

[funky-eyes]

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?

[sixlei]

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.

[funky-eyes]

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.

[sixlei]

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.

[LPBruce]

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

[funky-eyes]

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

ok