[infinispan-dev] hotrod's RemoteCacheManager

[Mircea Markus]

Thanks for the feedback!
> 

On 25 Mar 2010, at 02:18, Manik Surtani wrote:

> 
> On 24 Mar 2010, at 11:11, Mircea Markus wrote:
> 
>> I've checked in ongoing work of the hotrod client; it would be great to get some feedback on the public API, especially RemoteCache[1] and RemoteCacheManager[2].
>> For now RemoteCacheManager does not implement CacheManager interface, see email bellow.
>> 
>> [1] http://tinyurl.com/yhb793b
> 
> Looks good.  Shouldn't VersionedEntry be VersionedValue<V> ?  
> 
> Basically Cache.get(K) returns V.  So RemoteCache.getVersioned(K) should return VersionedValue<V> ?
good point. It's a Entry<K,V>, as it extends Map.Entry<K,V> 
> 
> 
>> [2] http://tinyurl.com/yh6j2we
> 
> Don't you want RemoteCacheManager to be an interface and a separate RemoteCacheManagerImpl or something?
I've been thinking about that; I wanted to copy the behaviour from core, in which we instantiate the DefaultCacheManagers directly. 
> 
> Also, maybe you want to also provide a constructor that takes in (Properties p, int numBossThreads, int numWorkerThreads) and (Properties p, int numBossThreads, int numWorkerThreads, ClientIntelligenceLevel cil) - or are these three (boss threads, worker threads, client intelligence level) all defined in properties?
these will all be defined in properties. It might make sense having an constructor that takes all the config props though.

> 
> 
>> 
>> Cheers,
>> Mircea
>> 
>> 
>> On 23 Mar 2010, at 23:16, Mircea Markus wrote:
>> 
>>> Hi,
>>> 
>>> While presenting the hot rod client java API in Brno, we agreed to use a RemoteCacheManager that would implement CacheManager (similar to the way in which DefaultCacheManager implements CacheManager; it is used for clients from the same namespace).
>>> Looking at the CacheManager interface[1], most of the methods that do not make sense on the RemoteCacheManager: defineConfiguration, getClusterName, getAddress, isCoordinator, getStatus, getGlobalConfiguration, getDefaultConfiguration and getCacheNames. 
>>> The only two methods that really make sense are: getCache() and getCache(cacheName:String). So here are some thoughts I have about having RemoteCacheManager implementing CacheManager.
>>> 1. Approach 1 - throw exceptions for the unsupported methods. Not a very nice approach IMO, given the fact that most of the methods fall in this category, which would make the API a bit unusable
>>> 2.  Approach 2 - do not extend it. This would result in a clearer API
>>> 3. Approach 2 - Extract the  two getCache methods in an super interface (CacheHolder, CacheRepository, ??) and have both CacheManager and RemoteCacheManager implement it - this one I like the most as it encourages reusability and keeps the API clean.
>>> 
>>> Thoughts?
>>> 
>>> Cheers,
>>> Mircea
>>> 
>>> [1] http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/manager/CacheManager.java
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100325/29494c18/attachment-0002.html