[infinispan-issues] [JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3633: ----------------------------------- This was a transactional cache, with default (read committed) isolation. Here is an excerpt from the logs, the full ones are on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-radargun-resilie... 08:38:28,313 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-21) Key key_000000000000491A modified by a regular tx, state transfer will ignore it 08:38:28,313 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-21) Entry for key key_000000000000491A is null : not calling commitUpdate Then later on, when executing StateResponseCommand: 08:38:45,514 TRACE [org.infinispan.transaction.LocalTransaction] (remote-thread-20) Adding modification PutKeyValueCommand{key=key_000000000000491A, value=[37 #1: 173, ], flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}. Mod list is null 08:38:45,526 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (remote-thread-20) State transfer will not write key/value key_000000000000491A/[37 #1: 173, ] because it was already updated by somebody else Therefore, for reproduction of this bug you need to get to this situation 1. A gets entry from B, caches that 2. state transfer from B to A begins (B is previous owner, A is new one) - some delay or many entries would be required here 3. entry is overwritten on B, invalidating A's record 4. when A get's the StateResponseCommand, the entry is not set 5. you may check the entry on A to be still null Is there anything that should prohibit this behaviour? Am I oversimplifying something? -- 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