[brian.stansberry]

We talked briefly about that kind of thing yesterday. Basically, that's along the lines of making Region a first level construct (which I'd definitely like!!). There's a JIRA for that. But for 2.0 it seems like too much work, as it requires major changes in the internal operation of the cache.

[manik]

From what we discussed, Cache will have a getRegion(Fqn) API, which will allow the caller to add context classloaders and eviction policies to the region. Regions can also be activated/deactivated in this way.

[ben.wang]

Another question is how can I override the Node implementation, specifically get. The use case is in buddy replication for PojoCache. When the Option is set to DataGravitation, the get will not only retrieve the data under the root node, it will also get it from the corresponding _JBOSS_INTERNAL_ region as well.

For this, I need to override the get API.

[manik]

Hmm, you would have to subclass TreeCacheProxyImpl, which is a wrapper around TreeCache that implements Cache, Node and the SPI interfaces.

I'd also have to make sure I always obtain a TreeCacheProxyImpl from a factory so I can retrieve the appropriate subclass. (This is a TODO)

Cheers,
Manik

[brian.stansberry]

One thing I see is there is no way to find out information about a cache's configuration via the Cache interface, you have to go to CacheSPI. That seems a little odd, as understanding at least some details about how a cache is configured is a reasonable concern of a cache user.

Example: session replication uses the cache in slightly different ways depending on whether region-based marshalling is on and whether BR and passivation are being used.

[manik]

Good point. Will move this to Cache rather than CacheSPI