[infinispan-issues] [JBoss JIRA] (ISPN-5158) Transaction rolled back but returns successful response

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-5158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033790#comment-13033790 ] 

Dan Berindei commented on ISPN-5158:
------------------------------------

After further investigation it turns out cache.withFlags(FORCE_WRITE_LOCK).get(k) is not affected. A ClusteredGetCommand with the acquireRemoteLocks=true can indeed cause a transaction rollback, but a get() will trigger a separate LockControlCommand instead of setting  acquireRemoteLocks=true.

Instead, the separate LockControlCommand is skipped and acquireRemoteLocks=true only for write operations with the SKIP_LOCKING flag set. I've created ISPN-5163 to describe the issue.

The current fix will remove the potential rollback from ISPN-5163, but the lock will still be acquired with the SKIP_LOCKING flag. 

> Transaction rolled back but returns successful response
> -------------------------------------------------------
>
>                 Key: ISPN-5158
>                 URL: https://issues.jboss.org/browse/ISPN-5158
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 7.1.0.Beta1
>            Reporter: Radim Vansa
>            Assignee: Dan Berindei
>            Priority: Critical
>         Attachments: tx.txt, views.txt
>
>
> When the cluster is merging, it is possible that a node is removed from the view although it is still responsive. Eventually the cluster is merged correctly, but since the node is reported as missing from the view, transaction originating from this node is rolled back.
> {code}
> 10:01:36,116 TRACE [org.infinispan.interceptors.TxInterceptor] (remote-thread-151) Rolling back remote transaction GlobalTransaction:<edg-perf02-39415>:28106:remote because either already completed(false) or originator no longer in the cluster(true).
> {code}
> However, even after this a successful response is sent to the originator:
> {code}
> 10:01:36,119 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-151) About to send back response null for command PrepareCommand {modifications=[PutKeyValueCommand{key=key_0000000000001318, value=[19 #1: 1195, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, gtx=GlobalTransaction:<edg-perf02-39415>:28106:remote, cacheName='testCache', topologyId=47}
> {code}
> Originator then expects that the transaction was successfully prepared:
> {code}
> 10:01:36,124 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-9) Responses: [sender=edg-perf01-36235, received=true, suspected=false]
> [sender=edg-perf03-24110, received=true, suspected=false]
> 10:01:36,135 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-9) Committing transaction GlobalTransaction:<edg-perf02-39415>:28106:local
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)