On 26 Jan 2012, at 14:52, Sanne Grinovero wrote: > On 26 January 2012 14:37, Mircea Markus <[email protected]> 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 :-)
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
