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.