Bug 1016054 - CommitCommand with replayed PrepareCommand executes rollback and then commit
CommitCommand with replayed PrepareCommand executes rollback and then commit
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ER4
: 6.2.0
Assigned To: Tristan Tarrant
Martin Gencur
Depends On:
Blocks: 1017190
  Show dependency treegraph
Reported: 2013-10-07 08:14 EDT by Radim Vansa
Modified: 2013-11-21 03:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ISPN-3599 Critical Resolved CommitCommand with replayed PrepareCommand executes rollback and then commit 2013-11-27 07:00:30 EST

  None (edit)
Description Radim Vansa 2013-10-07 08:14:25 EDT
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.
Comment 1 JBoss JIRA Server 2013-10-07 09:28:37 EDT
Dan Berindei <dberinde@redhat.com> made a comment on jira ISPN-3599

[~rvansa], does this cause any inconsistencies?
Comment 3 JBoss JIRA Server 2013-10-08 03:17:29 EDT
Radim Vansa <rvansa@redhat.com> made a comment on jira 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.
Comment 4 JBoss JIRA Server 2013-10-10 06:07:31 EDT
Pedro Ruivo <pedroruivo2@gmail.com> updated the status of jira ISPN-3599 to Coding In Progress
Comment 5 JBoss JIRA Server 2013-10-10 07:42:11 EDT
Pedro Ruivo <pedroruivo2@gmail.com> made a comment on jira ISPN-3599

Good catch [~rvansa]

Note You need to log in before you can comment on or make changes to this bug.