[belaban]

Hmm, I actually do like a separate event, nodeMoved(olfFqn, newFqn).
Up to you

[belaban]

I want to remind everyone why we do this extensive amount of refactoring:
- Cleaner code by removing unnecessary methods from the main cache interface (e.g. methods only accessed by interceptors will be in the SPI).
- JSR 107 (JCache) compliance

So let's strive to remove as much as we can from Cache, *not* add to it !

[belaban]

I don't think so, this will lead to a proliferation of 'proxies to maps'...

[belaban]

I look at NotificationListener as a excellent way of how *not* to do it, this is similar to reducing everything to ioctl() rather than having read(), write() etc

[galder.zamarreno]

I think it all comes down to how the events will evolve, do we expect more
events to be created in the future? Doing it in a NotificationListener way would
enable us extend the events very easily.

Bela, what problem do you see having proxies to maps? Being tied to the
evolution of (Concurrent)HashMap?

+1 on the Configuration.
+1 lifecycle methods to be part of Cache.

[genman]

I am not suggesting a single method listener. A simple compromise might be that you retain 3-4 methods, and use Event classes (of appropriate types) instead. From a useability and expandability point of view, you need to create an API that is easy for clients to implement and lasts more than a few versions.

It's also thought that any time you have methods with more than 2-3 arguments you should create an object for them...

 CacheFactory cf = new CacheFactoryImpl();

JSR-107 has a CacheManager that handles this.

I would expect in a J2EE environment, you would probably "bind" this factory to JNDI, then look it up, not create it directly.

- JSR 107 (JCache) compliance

The point of having the (Concurrent)Map part of Node.getData() be a proxy for cache access, is that it actually follows the spirit of JSR-107. Notice that javax.cache.Cache extends Map.

You could easily write a class that could do something like this:

javax.cache.Cache cache = new JSR107Cache(jbossCache.getNode("/foo/bar"));

evolution of (Concurrent)HashMap?

The ConcurrentMap interface will never be expanded, as far as I know. This is somewhat limiting I guess.

[galder.zamarreno]

However, I think, as said earlier, that a Cache is not a Map. A Cache can be represented in different forms, such as a Tree, Map...etc.

In my mind, a Cache should not be linked to a way of storing data.

[manik]

Hmm, while I do like the idea of providing a proxy to the maps and allowing users to directly modify the child and data maps of a node, I think we will have to defer this for 2.0.0 as this will open up a can of worms, esp. when implementing the Map methods, dealing with Iterators, etc.

Maybe for 2.1.0? :-)

[manik]

Some of the comments regarding the design on the wiki, summarised from this thread + direct discussions with certain individuals:

* Remove getCacheSPI() and getNodeSPI() methods
* Add putIfNull() on Node
* Add convenience methods on Cache: put(Fqn, key, value) and get(Fqn, key) and remove(Fqn, key)
* Remove evict() and load() on NodeSPI?
* Add evict(recursive) on Cache
* Add Cache.getMarshaller()
* Add a Marshaller(?) interface (publicly accessible to manipulate marshalling behaviour)
o Marshaller.register(Fqn, ClassLoader)
o Marshaller.unregister(Fqn)
o Marshaller.activate(Fqn)
o Marshaller.deactivate(Fqn)

[manik]

CacheException to extend RuntimeException

[brian.stansberry]

* Add Cache.getMarshaller()
* Add a Marshaller(?) interface (publicly accessible to manipulate marshalling behaviour)

Do we want to allow programmatic addition/removal of eviction regions? If so, perhaps it should be getRegionManager() instead of getMarshaller(). Then all the API related to regions is exposed in that interface.

[manik]

Is such programmatic manipulation a feature we'd need? Is this because such regions change dynamically, or because their values are not known till runtime? Or simply because people don't like config files? :)

[brian.stansberry]

I think I recall seeing user forum discussions of dynamic eviction configuration. Some guy with hundreds of regions?

EJB 2.0 allows per-bean configuration of things like SFSB cache pool sizes and passivation timeouts. To do the same kind of thing for EJB 3, we'd need programmatic configuration as well.

In general, as a guy who writes independent services that share a cache, I like programmatic configuration that can be used after the cache is started.

[ben.wang]

Brian and I just discussed about region manager for ejb3 sfsb replication. We realized that we will need to expose an API for user to contruct the eviction policy programtically. Then the logical way is to combine the RegionManager in marhsaller and eviction in 2.0 such that one *REGION* will share the same eviction and same marshaller.

If we do that, then we don't expose the Marshaller api. Instead, we expose either the getRegion or getRegionManager API such that I can register both the marshaller and eviction policy.

[genman]

I wonder if the listener stuff could be combined into the RegionManager along with the marshalling and eviction policy configuration. And actually cache loading and stuff like that seems to belong in a region.