[infinispan-dev] about cache.getCacheManager()

[Mircea Markus]

On 23 Aug 2010, at 14:18, Manik Surtani wrote:

> How about getCacheManager() returning an EmbeddedCacheManager (if in-VM),
+1.
> and returning null if called on a RemoteCache,
What about throwing an exception and telling the user to use RemoteCache.getRemoteCache instead?
> and RemoteCache defining a separate getRemoteCacheManager() method?
That's already there ;)
> 
> On 23 Aug 2010, at 11:28, Sanne Grinovero wrote:
> 
>> Some comments inline:
>> 
>> 2010/8/23 Mircea Markus <mircea.markus at jboss.com>:
>>> On 21 Aug 2010, at 00:50, Sanne Grinovero wrote:
>>> 
>>>> Hello,
>>>> I was quite surprised to see that
>>>> cache.getCacheManager() doesn't return the CacheManager but a
>>>> CacheContainer, which I then need to cast to an EmbeddedCacheManager.
>>> This was introduced with HotRod client. Both embedded and remote (hotrod) caches inherit from the same Cache interface. Also the structure that holds the caches is not a cache manager, but the CacheContainer - that's all that an remote and embedded cache container have in common.
>>>> Shouldn't the signature of the interface be updated to return a CacheManager ?
>>> I agree this method name is misleading and it breaking the API from 4.0. One thing we can do is:
>>> - make getCacheManger return an EmbeddedCacheManager and deprecate it - to solve backward compatibility
>> 
>> I don't think you need to deprecate it: current code was not released
>> yet and previous release was returning a supertype of
>> EmbeddedCacheManager.
>> 
>>> - when called on an RemoteCache this would thrown an exception
>> Maybe it would make sense for a next release to return the
>> configuration of the remoted cache, possibly with additional
>> information about the remoting configurations.This way the Hot Rod
>> client would be more similar to the standard cache, maybe even
>> configured with a similar XML approach (just thinking out loud).
>> 
>>> - add a method Cache.getCacheContainer that would return an CacheContainer - this would be the suggested approach from now one
>> 
>> I'd like to actually make use of getCacheManager, not
>> getCacheContainer, as I need to read the configuration; so I wouldn't
>> suggest the new method nor deprecate the getCacheManager.
>> 
>>>> The methods exposed by a CacheContainer are rather useless, especially
>>>> when returned from a cache instance as the only two I could use are
>>>> getCache() and getCache(String cacheName); a use case to explain it
>>>> better:
>>>> 
>>>> ((EmbeddedCacheManager)cache.getCacheManager()).getGlobalConfiguration()
>>>> 
>>>> Cheers,
>>>> Sanne
>>> I see what you mean. I do think that this CacheContainer abstraction has some benefits though: it allows one to write code that doesn't know weather it is using an embedded or a remote cache.
>> 
>> Ok now that you pointed me to the RemoteCacheManager I understand the reasons.
>> I'm fine with making no changes for now, but as it turns out that I've
>> to cast often this defeats the purpose of being independent from the
>> cache type.
>> An alternative would be to use
>> getConfiguration().getGlobalConfiguration(), but this latest one was
>> deprecated and moved to the EmbeddedCacheManager, so maybe even
>> getCacheManager() should be moved to the new implementation?
>> 
>> Sanne
>> 
>> _______________________________________________
>> 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