-
1. Re: putForExternalRead doesn't write to owner
cyron Mar 25, 2013 12:21 AM (in response to sebastiantusk)Hello, Sebastian.
from the javadoc of putForExternalRead, invalidation does not take place.
you can also reference this.
-
2. Re: putForExternalRead doesn't write to owner
sebastiantusk Mar 25, 2013 4:44 AM (in response to cyron)While putForExternalRead doesn't invalidate anything, the entry stored with putForExternalRead has to be invalidated by other write operations like Cache.put or Cache.remove. That usually works just fine and as expected. To cite and modify the example from the link you posted.
- Node A reads X from some data store, then calls cache.putForExternalRead(X,Y), pushing some distinct object X into the cache.
- Node B then calls cache.put(X,Z).
- Node A's copy of X is invalidated.
This is what usually happens and would be correct behaviour. What actually happens is the following.
- Node A reads X from some data store, then calls cache.putForExternalRead(X,Y), pushing some distinct object X into the cache.
- Node B then calls cache.put(X,Z).
- Node A's copy of X is never invalidated.
Here something goes wrong in step 1. Node B should register that Node A has an entry by a call to L1ManagerImpl.addRequestor and use this to invalidate Node A in step 2.
-
3. Re: putForExternalRead doesn't write to owner
dan.berindei Mar 25, 2013 2:26 PM (in response to sebastiantusk)Hi Sebastian
cache.putForExternalRead(k, v) should be replicated on the key k's owners as well, and the originator should be registered as an L1 "requestor" for key k. However I did a quick check in the Infinispan test suite and I didn't find any test for putForExternalRead in distributed mode. Would you mind creating an issue in JIRA for this?
As a workaround, you could set your L1 invalidationThreshold to "0", so that L1 invalidations are always broadcasted to the entire cluster.
-
4. Re: putForExternalRead doesn't write to owner
sebastiantusk Mar 26, 2013 9:16 AM (in response to dan.berindei)Hi Dan,
thanks for your answer. I submitted ISPN-2964. Your workaround could indeed help with this specific problem. Unfortunately I have other issues with putForExternalRead, L1 and invalidation. See ISPN-2913 and ISPN-2965. For ISPN-2913 and ISPN-2964 I have fixes but for the third issue I do not have a clue how to approach it. The problem seems to be that writing an entry sends out invalidations but leaves after that a gap where other nodes can retrieve old values. These old values are put into L1 and not invalidated. Leading to a state where one node returns current values and the other one out-dated values. Something like this:
- Prepare cache by adding an entry with Cache.put( k, v1 ).
- Node B starts with adding a changed value. Cache.put( k, v2 )
- Node B TxDistributionInterceptor.visitPrepareCommand - flushL1Caches sends invalidations.
- Node A calls Cache.get( k ) retrieves v1 and stores this value in L1.
- Node B proceeds with transaction.
- A has v1. B has v2.