]
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