Replacing our Replicated Caches with Distributed+CQC

Question

Hi,
I've been advised on this forum to replace our Replicated caches with Distributed+CQC with an AlwaysFilter. This should give me the "zero-latency" get() performance which really should be part of a Replicated Cache, but apparently isn't (the lease-model and serialization get in the way of this).
My concern is now storage efficiency - my understanding is that my storage footprint will double, as the same information is now stored in two places (partitioned backing map and cqc front map). Is this correct? If so, I'm unsure why it would be considered a good replacement for the Replicated scheme.
Thanks,
Matt

Answer 1

The second link looks like it helped you out
- Re: The effects of "leases" on the read-performance of Replicated Caches
Also if you are looking at (near) zero latency when garbage collections occur, you might want to have at the Zing JVM
- http://www.azulsystems.com/products/zing/virtual-machine
Layency due to garbage collection (i.e., introduced pause times) could break your (extreme) low-latency demand.
You could try the CQC with the always filter:
NamedCache cache = CacheFactory.getCache("somecache");
ContinuousQueryCache localCache =new ContinousQueryCache(cache, AlwaysFilter.INSTANCE);The preceding code will result in a locally materialized view of the cache data that satisfies the specified filter. By default, both keys and values will be cached locally.
If you want to cache only keys and retrieve values from the back cache as needed, which might be the best option if the values are large and accessed infrequently, or
if you only care about having an up-to-date keyset locally, you can pass false as the third argument to the CQC constructor.
To get data from the CQC you can use
Iterator<Map.Entry<Integer, Klant>> data = localCache.entrySet().iterator();