-
1. Re: ClusteredCacheLoader should be configured as shared?
manik Jun 6, 2007 7:07 AM (in response to brian.stansberry)Minor problem is a bug. CCL should not deal with writes. Write methods should be no-ops.
Major problem too is a bug - even if the remove() does have to return the old value, the propagated call should be a get() to retrieve the old value, not a remove().
A valid workaround for both should be to set ignoreModifications to true. -
3. Re: ClusteredCacheLoader should be configured as shared?
brian.stansberry Jun 6, 2007 10:35 AM (in response to brian.stansberry)I wasn't clear on the "Major" issue. CCL isn't propagating the remove; the issue there happens when the normal and perfectly correct replication of a remove call occurs. But then on the remote machine, as it tries to handle the remove, the CCL ends up doing a clustered get.
-
4. Re: ClusteredCacheLoader should be configured as shared?
manik Jun 6, 2007 11:11 AM (in response to brian.stansberry)Ah right - even worse then.
-
5. Re: ClusteredCacheLoader should be configured as shared?
manik Jun 6, 2007 11:12 AM (in response to brian.stansberry)basically the CCL returning anything for a remove() call is the fault. This does (somewhat) break the CacheLoader contract in that the remove() method should always return the old value, but the CCL does have somewhat different behaviour.
-
6. Re: ClusteredCacheLoader should be configured as shared?
manik Jun 6, 2007 11:27 AM (in response to brian.stansberry)Interestingly enough, the put() method in CCL checks for the origin of the method call and only does a clusterwide get() if the origin is local. remove() ought to do the same.
Regarding both though, the CCL could peek() into the cache and see if the value exists locally first. The network call is unnecesary and inefficient. -
7. Re: ClusteredCacheLoader should be configured as shared?
brian.stansberry Jun 6, 2007 11:58 AM (in response to brian.stansberry)+1 on both your last comments. Makes sense.
Re: the shared flag, one of the reasons I was thinking that way was this eval of CCL was for a support case where only config changes were possible. It seems like that worked fine for the http session repl use case, at least with SESSION granularity where the use of the cache is pretty basic.