[
https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-3599:
-----------------------------------
Actually, I am not sure - I've noticed this behaviour when tracking down ISPN-3600
(and the inconsistency was caused by the 3600). However, I believe that it can lead to
inconsistency as the locks are released (is it, during the rollback, right?) before the
entries are committed.
CommitCommand with replayed PrepareCommand executes rollback and then
commit
----------------------------------------------------------------------------
Key: ISPN-3599
URL:
https://issues.jboss.org/browse/ISPN-3599
Project: Infinispan
Issue Type: Bug
Components: State transfer, Transactions
Affects Versions: 6.0.0.CR1
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
During state-transfer in tx cache, the node can receive {{CommitCommand}} from other
node. After the node gets transaction data for affected segments, it creates the
transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be
executed.
In this command's {{perform(...)}} the transaction is *first* marked as completed,
then it enters the interceptor chain. There, the {{PrepareCommand}} is created in
{{StateTransferInterceptor.visitCommitCommand}} but after this is processed the
{{TxInterceptor}} finds out that the transaction is already completed and executes
{{RollbackCommand}}, clearing locks etc.
Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}}
afterwards. I suspect that this may be executed without the locks held.
Anyway, it is not correct to execute both commit and rollback on the same transaction.
--
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