[infinispan-issues] [JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

[Mircea Markus (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mircea Markus updated ISPN-3599:
--------------------------------

    Labels: 620 nbst  (was: 620)

    
> 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: Pedro Ruivo
>            Priority: Critical
>              Labels: 620, nbst
>             Fix For: 6.0.0.Final
>
>
> 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