Hi Chris!
> Your description of the behavior is correct. I guess its a matter of the
> exact meaning of the two flags as to whether this is the intended behavior
> or not. I'd tend to side with you here and declare it a bug as in my mind a
> non present mapping isn't local.
Exactly.
You just need to change the clause as follows:
if (val == null &&
lockStrategy.allowNonCoherentReadsForNonExistentMapping()) {
// Mapping not present and we are allowed to perform fast
non-coherent reads for non-existent mapping.
return null;
} else if (val != null & !(val instanceof ObjectID) &&
lockStrategy.allowNonCoherentReadsForLocalEntries()) {
// Mapping present and is faulted in and we are allowed to
perform fast non-coherent reads for locally present mapping.
return (V) val;
}
I tested it locally and everything is fine.
Do you want me to file a jira issue and commit the fix (I have commit
access to the forge), or do you want to fix it by yourself?
Moreover, is it possible to issue a new module release as soon as the
bug is fixed (which is why I'm adding Jason to the thread)?
Thanks!
Sergio B.
--
Sergio Bossa
Software Passionate and Open Source Enthusiast.
URL: http://www.linkedin.com/in/sergiob
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
