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>>

Cheers Manik -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 May 2010, at 15:33, Mircea Markus wrote: >> >> 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. Yeah I don't think such complications should be encouraged. :)

> 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? This is used when putting stuff in the data container after loading from the cache loader. If the information is not present then stuff becomes immortal which may be incorrect. -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 May 2010, at 17:22, Manik Surtani wrote: >> 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. Is it the same for fromStream/toStream