[infinispan-dev] thoughts on RemoteCacheStore

Mircea Markus mircea.markus at jboss.com
Mon May 24 10:33:14 EDT 2010


On 24 May 2010, at 17:22, Manik Surtani wrote:

> 
> On 24 May 2010, at 15:00, Mircea Markus wrote:
> 
>> Hi,
>> 
>> 1. Do we want this to be a CacheStore or CacheLoader only? Looking at TcpDelegatingCacheLoader it also does puts, guess we want to preserve the same behaviour - or?
> 
> Yes, it should be a store.
> 
>> 2. load/loadAll/loadAllKeys operations cannot be implemented (hotrod does not support getKeys, and even so that would potentially be too costly) 
> 
> Yes, these are only used when state transfer/rehashing/preloading is enabled, and none of these make sense for a *shared* cache store.  Typically, a RemoteCacheStore would be shared so this code would not be called.  An UnsupportedException (with an explanation: RemoteCacheStore can only run in shared mode!) should be thrown.
> 
>> 3. at chacheStore level we have InternalCacheEntry, whilst RemoteCache operates with the actual key/value operations. This means that (at least on get) the expiration information is lost.
> 
> Hmm, perhaps then RemoteCache should put(key, InternalCacheValue) so that this stuff is not lost?  On get(key), you get a InternalCacheValue.  I.e., your RemoteCache should be a RemoteCache<K, InternalCacheValue<V>>
I guess it depends on the setup. If remote cluster is "independent", e.g. used by other parties as an EmbeddedCache or even as anCacheServer through hotrod, then it can only contains actual key-values. Otherwise, if the cluster is *only* used as an remote store, then your approach works.
Timestamp information is not lost on puts (put(k,v. duration) being called on remote cache, but on get only - where is this information used on gets?
> 
> Cheers
> Manik
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev




More information about the infinispan-dev mailing list