Bug 1016054 - CommitCommand with replayed PrepareCommand executes rollback and then commit
Summary: CommitCommand with replayed PrepareCommand executes rollback and then commit
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER4
: 6.2.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks: 1017190
TreeView+ depends on / blocked
 
Reported: 2013-10-07 12:14 UTC by Radim Vansa
Modified: 2025-02-10 03:28 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-02-10 03:28:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-3599 0 Critical Resolved CommitCommand with replayed PrepareCommand executes rollback and then commit 2013-11-27 12:00:30 UTC

Description Radim Vansa 2013-10-07 12:14:25 UTC
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 13:28:37 UTC
Dan Berindei <dberinde> made a comment on jira ISPN-3599

[~rvansa], does this cause any inconsistencies?

Comment 3 JBoss JIRA Server 2013-10-08 07:17:29 UTC
Radim Vansa <rvansa> 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 10:07:31 UTC
Pedro Ruivo <pedroruivo2> updated the status of jira ISPN-3599 to Coding In Progress

Comment 5 JBoss JIRA Server 2013-10-10 11:42:11 UTC
Pedro Ruivo <pedroruivo2> made a comment on jira ISPN-3599

Good catch [~rvansa]

Comment 6 Red Hat Bugzilla 2025-02-10 03:28:38 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


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