[
https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-4137:
------------------------------------
Indeed [~rvansa], waiting for a human intervention doesn't sound very good. Before
starting the work on this I was convinced that's how recovery is supposed to work, now
I'm not so sure...
Without recovery, we will still run the rollback to make sure the locks are released. I
don't have any suggestions on how to improve that, except maybe retrying the commit
indefinitely.
If the primary owner crashes, the txs on the backup owners still have "backup
locks". Each prepare on the new primary owner will check in the entire tx table for
backup locks, and will block until those locks are released. The real problem is when the
originator dies...
Transaction executed multiple times due to forwarded CommitCommand
------------------------------------------------------------------
Key: ISPN-4137
URL:
https://issues.jboss.org/browse/ISPN-4137
Project: Infinispan
Issue Type: Bug
Components: State Transfer, Transactions
Reporter: Radim Vansa
Assignee: Dan Berindei
Priority: Critical
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira