Dan Berindei created ISPN-11256: ----------------------------------- Summary: Context entries should always be MvccEntries Key: ISPN-11256 URL: https://issues.redhat.com/browse/ISPN-11256 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 10.1.1.Final Reporter: Dan Berindei Fix For: 11.0.0.Final We optimize reads by storing {{InternalCacheEntry}} instances directly in the {{InvocationContext}}, instead of creating a {{ReadCommittedEntry}} or a {{RepeatableReadEntry}}. This helps {{READ_COMMITTED}} behave like users expect it to, at least in local mode with OBJECT storage: since the context has a reference to the entry in the data container, the transaction sees external updates automatically. I also see this as a negative, though, becase it's practically impossible to extend it to work with distributed caches or with off-heap storage. The downside is that reading from the entry in the context is racy, so we need {{synchronized}} blocks everywhere, and me may even be missing {{synchronized}} in some places. It also means that things like {{ReadCommittedEntry.isLoaded()}} don't if the command that triggered the load from the store was a read, because there is no {{ReadCommittedEntry}}. I suggest always wrapping the entry in a {{MvccEntry}}, and making {{READ_COMMITTED}} caches re-fetch the entry on every read to see external updates (maybe guarded by a flag/configuration attribute). {{SingleKeyNonTxInvocationContext}} may avoid the extra allocation by implementing {{MvccEntry}} itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)