[infinispan-issues] [JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-4720:
------------------------------------

Prashant, could you explain in more detail what you expect to see and what is actually happening? Ideally, you could attach the entire log (or at least a longer portion of it) and the configuration?

Note that even if you configure isolation mode READ_COMMITTED, Infinispan will behave more like with REPEATABLE_READ. Modifications to entries that are stored on the node that started the transaction are visible in the transaction, but modifications to keys stored on another node will only be seen by a new transaction.

> Values data reverts in Compatibilty mode in Infinispan 6.0.2
> ------------------------------------------------------------
>
>                 Key: ISPN-4720
>                 URL: https://issues.jboss.org/browse/ISPN-4720
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 6.0.2.Final
>         Environment: Linux 3.15.8-200.fc20.x86_64
>            Reporter: Prashant Thakur
>            Assignee: Dan Berindei
>            Priority: Critical
>              Labels: Infinispan
>
> 1) The owners of the keys are Node1 and Node4
> 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1.  Owners are [blrsrv29-4565, blrsrv42-19390]
> 2.	 The request for update came to Node2 a non-owner.
> 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED}
> 3.	The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data.
> 4. While doing a get from Node 1 we again receive the old value



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)