<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 12:48 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 21 May 2013, at 17:09, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
<br>
> I wouldn't want to deprecate CCL, I think it definitely has a purpose - at least in invalidation mode.<br>
</div>The only use case I'm aware of for invalidation is 2nd level cache and I don't think that needs a remote cache, Galder wdyt?<br></blockquote><div><br></div><div>I don't know if 2nd level cache actually uses ClusterCacheLoader, but it could definitely use it without exposing the cache through HotRod.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">><br>
> Even in replication mode, having a lazy alternative to state transfer may be useful. Maybe not for the topology cache, but it might make sense for large caches.<br>
<br>
</div>this makes me wonder: what would be the case in which one doesn't want to use state transfer for a distributed/replicated cache.<br></blockquote><div><br></div><div>In replication mode, if the cache has a huge (non-shared) cache store, some users may prefer to disable fetchPersistentState and rely on ClusterCacheLoader instead for less frequently accessed keys.<br>
<br></div><div>I don't know if it ever makes sense to use ClusterCacheLoader in distribution mode, since it always sends the ClusteredGetCommand to the entire cluster.<br></div><br></div><br>Cheers<br></div><div class="gmail_extra">
Dan<br><br></div></div>