[
https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-3745:
------------------------------------
Is topologyId = 18 the id of the topology that contains the joiner, or the topology
before? If it's the new topology, and the command was initially invoked remotely with
topology 17, then the command was forwarded, otherwise it was likely retransmitted by
JGroups.
I'm inclined to think it's caused by JGroups retransmitting the message to the
joiner and the originator not waiting for the response, too.
Forwarded Prepare/Commit executed after transaction finished
------------------------------------------------------------
Key: ISPN-3745
URL:
https://issues.jboss.org/browse/ISPN-3745
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 6.0.0.Final
Reporter: Radim Vansa
Assignee: Dan Berindei
Priority: Critical
Labels: 620
Replicated TX cache, nodes A, B, C
0. A and B have topology 2, C already got topology 3
1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
2. C forwards prepare to B with topology 3
3. A sends commit with topology 2 to B and C, both commit and respond
4. again, C forwards prepare to B with topology 3
5. A and B get updated topology id
6. A executes another transaction on the same entry
7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites
(or removes) the entry again
Result: on B we have inconsistent state
--
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