-
Bug
-
Resolution: Done
-
Critical
-
None
When the StateTransferInterceptor forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see STI.visitCommitCommand.
However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
- is related to
-
ISPN-3599 CommitCommand with replayed PrepareCommand executes rollback and then commit
- Closed
-
ISPN-4262 Rolling back a transaction after commit timeout should release locks in two phases
- Closed
-
ISPN-4293 PR for ISPN-4137 causes a performance drop in repl tx mode
- Closed
- relates to
-
ISPN-4517 RollbackCommands should ignore leavers
- Closed