[infinispan-issues] [JBoss JIRA] (ISPN-11256) Context entries should always be MvccEntries

[Tristan Tarrant (Jira)]

     [ https://issues.redhat.com/browse/ISPN-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tristan Tarrant updated ISPN-11256:
-----------------------------------
    Fix Version/s: 12.0.0.Final
                       (was: 11.0.0.Final)


> 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
>            Priority: Major
>             Fix For: 12.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)