[infinispan-dev] Placement for ISPN-905 API

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Placement for ISPN-905 API

Galder Zamarreno
Hi all,

I'm working on https://issues.jboss.org/browse/ISPN-905 and just wanted to explain the interface where these methods will be added and why in case anyone differs:

I had initially thought of adding them to CacheContainer but doing that implies that they have a meaning for the RemoteCacheManager.

So, could a remote client call removeCache("x"), taking in account that it does both remove the contents of the cache and any cache loader attached to it, plus stops the cache? Remote clients can currently clear caches, but cannot stop them, so it would not make sense to do this right now given the current remote client capabilities. Also, we agreed not to allow remote clients to stop things in order to reduce potential security issues,

On top of the logical argument, there's a problem of API incompatibility with RemoteCacheManager. If we'd want to add getCache(String, Boolean) to CacheContainer, this would clash with RemoteCacheManager's:

public <K, V> RemoteCache<K, V> getCache(boolean forceReturnValue);

So, that would have forced us to provide a different name in CacheContainer to avoid clashing with this method, and that in turn would have resulted in breaking simmetry with other similar APIs such as AtomicMapLookup API where we define:

public static <MK, K, V> AtomicMap<K, V> getAtomicMap(Cache<MK, ?> cache, MK key, boolean createIfAbsent);

Bottom line, the method suggested by https://issues.jboss.org/browse/ISPN-905 will be included in EmbeddedCacheManager.

If anyone has any different opinions, post reply :)

Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Placement for ISPN-905 API

Patrick McFarland
On Fri, Feb 25, 2011 at 12:02 PM, Galder Zamarreño <[hidden email]> wrote:
> Hi all,
>
> I'm working on https://issues.jboss.org/browse/ISPN-905 and just wanted to explain the interface where these methods will be added and why in case anyone differs:
>
> I had initially thought of adding them to CacheContainer but doing that implies that they have a meaning for the RemoteCacheManager.
>
> So, could a remote client call removeCache("x"), taking in account that it does both remove the contents of the cache and any cache loader attached to it, plus stops the cache? Remote clients can currently clear caches, but cannot stop them, so it would not make sense to do this right now given the current remote client capabilities. Also, we agreed not to allow remote clients to stop things in order to reduce potential security issues,

I don't particularly understand the point of RemoteCacheManager.
Doesn't it greatly limit its use if it can't do everything an
EmbeddedCacheManager can do as well?

> On top of the logical argument, there's a problem of API incompatibility with RemoteCacheManager. If we'd want to add getCache(String, Boolean) to CacheContainer, this would clash with RemoteCacheManager's:
>
> public <K, V> RemoteCache<K, V> getCache(boolean forceReturnValue);
>
> So, that would have forced us to provide a different name in CacheContainer to avoid clashing with this method, and that in turn would have resulted in breaking simmetry with other similar APIs such as AtomicMapLookup API where we define:
>
> public static <MK, K, V> AtomicMap<K, V> getAtomicMap(Cache<MK, ?> cache, MK key, boolean createIfAbsent);
>
> Bottom line, the method suggested by https://issues.jboss.org/browse/ISPN-905 will be included in EmbeddedCacheManager.

I'm the one that requested these features, and I don't plan on ever
using RemoteCacheManager (nor allow user provided CacheManager
instances; the inside of my stuff is a black box of sorts), so this
doesn't really effect me.

> If anyone has any different opinions, post reply :)
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



--
Patrick "Diablo-D3" McFarland || www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Placement for ISPN-905 API

Manik Surtani
In reply to this post by Galder Zamarreno

On 25 Feb 2011, at 17:02, Galder Zamarreño wrote:

> Hi all,
>
> I'm working on https://issues.jboss.org/browse/ISPN-905 and just wanted to explain the interface where these methods will be added and why in case anyone differs:
>
> I had initially thought of adding them to CacheContainer but doing that implies that they have a meaning for the RemoteCacheManager.
>
> So, could a remote client call removeCache("x"), taking in account that it does both remove the contents of the cache and any cache loader attached to it, plus stops the cache? Remote clients can currently clear caches, but cannot stop them, so it would not make sense to do this right now given the current remote client capabilities. Also, we agreed not to allow remote clients to stop things in order to reduce potential security issues,

remove() should only be in Embedded.

>
> On top of the logical argument, there's a problem of API incompatibility with RemoteCacheManager. If we'd want to add getCache(String, Boolean) to CacheContainer, this would clash with RemoteCacheManager's:

Again, this too should be in Embedded.  RemoteCaches have no ability to deal with lifecycle.

> public <K, V> RemoteCache<K, V> getCache(boolean forceReturnValue);
>
> So, that would have forced us to provide a different name in CacheContainer to avoid clashing with this method, and that in turn would have resulted in breaking simmetry with other similar APIs such as AtomicMapLookup API where we define:
>
> public static <MK, K, V> AtomicMap<K, V> getAtomicMap(Cache<MK, ?> cache, MK key, boolean createIfAbsent);
>
> Bottom line, the method suggested by https://issues.jboss.org/browse/ISPN-905 will be included in EmbeddedCacheManager.

Yep.  :-)

>
> If anyone has any different opinions, post reply :)
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev