[infinispan-dev] DIST.retrieveFromRemoteSource

[Mircea Markus]

On 26 Jan 2012, at 14:52, Sanne Grinovero wrote:

> 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.
+1, having null markers in L1 might increase performance for certain scenarios.
> 
> 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.
that's actually applicable for Optimistic locking as well :-)