Re: [infinispan-dev] DIST.retrieveFromRemoteSource

On 26 January 2012 14:37, Mircea Markus <mircea.markus(a)jboss.com&gt; 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.