[infinispan-dev] DIST.retrieveFromRemoteSource

[Sanne Grinovero]

On 26 January 2012 14:37, Mircea Markus <mircea.markus at jboss.com> wrote:
>>> I'd like to have Dan's input on this as well first, as he has worked with
>>> remote gets and I still don't know why null results are not considered valid
>>> :)
>>
>> Pre-5.0 during state transfer an owner could return null to mean "I'm
>> not sure", so the caller would ignore it unless every target returned
>> null.
>> That's no longer necessary, but it wasn't broken so I didn't fix it...
>
> Thinking some more about this, it actually has an performance impact: if the entry does not exist then there's no point in waiting for all replies, but juts for the first one.

Of course, and there are more performance-affecting details: maybe you
know it's not existing, but this information is not cacheable in L1.
When having passivation, you might need to look into the cachestore to
make sure, etc...

It might be worth to consider having alternative strategies to store
null, like using some marker. This introduces however the problem of
garbage collection of entries pointing to this marker: but this
problem might not be a problem for some applications, or we use
LIRS/LRU as it's just an optimization: we can afford losing the
specific information.

As I've mentioned to Manik in London, we will likely need markers
anyway to resolve conflicts with MVCC: if a thread replaces K1,
another removes it, and then another adds it back.. the version
information was lost during the delete operation.