Hello Mindaugas, I'm pretty fond on the way I can create multiple caches relying on the same cacheManager (and thus sharing the transport layer); I was recently having a similar requirement and - while the keys are of course of unpredictable number - the number of groups was limited and for defined specialized purposes, so I created different caches, giving them names after the group. So returning to your code: Cache<Object, Object> cacheX = manager.getCache("groupX"); Cache<Object, Object> cacheY = manager.getCache("cacheY"); cacheX.put("key1", "value1"); cacheX.put("key2", "value2"); cacheX.clear();  // this would evict both key1 and key2 as they belong to groupX, but not the values in cacheY You get the additional benefit of generics: giving different types to cacheX and cacheY might be cool if you can. Also it's nice if you later decide to tune some parameters of cacheX that it's independently configurable from cacheY. Even if you like this solution, you're still welcome to contribute :-D Regards, Sanne 2009/12/1 Mindaugas Žakšauskas <mindas(a)gmail.com&gt;: > Hi there, > > I am in process of reviewing Infinispan as, among other things, a > replacement of OSCache library we currently use. So far, it looks very > promising project - well done, guys! > > Anyway, one of the features we heavily rely on seems to be missing. > The feature is called "grouping", allowing to "bind" multiple > components and possibly flush them even without knowing of their keys. > E.g.: > > Cache cache = ....; > cache.put("key1", "value1", "groupX"); > cache.put("key2", "value2", "groupX"); > cache.flushGroup("groupX");   // this would evict both key1 and key2 > as they belong to groupX > > For more details, you can have a look at [1]. > > I've looked at the Infinispan's roadmap/JIRA, but couldn't find a > single trace of this feature mentioned anywhere. > > My question is, how hard would be to implement this feature without > having much knowledge of Infinispan internals? I've spoken to Manik > Surtani at Devoxx'09 and he guessed this could be done by using > interceptors. I've had a sneak peek at the interceptors package, but > obviously this is still pretty low level stuff, and apart from > javadocs, documentation resources are rather scarce. > > Chances are, I could get some time assigned to implement this feature > myself and contribute the code back to the community, but before doing > anything I'd like to know how feasible is this in general. For > example, what would be the best way to fit these parameters in the > current API? How would this work cluster-wise? > > Any ideas are appreciated. Thanks in advance! > > Regards, > Mindaugas > > [1] http://www.opensymphony.com/oscache/api/com/opensymphony/oscache/base/Cac... > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 12/01/2009 06:48 PM, Mindaugas Žakšauskas wrote: > Hi there, > > I am in process of reviewing Infinispan as, among other things, a > replacement of OSCache library we currently use. So far, it looks very > promising project - well done, guys! > > Anyway, one of the features we heavily rely on seems to be missing. > The feature is called "grouping", allowing to "bind" multiple > components and possibly flush them even without knowing of their keys. > E.g.: > > Cache cache = ....; > cache.put("key1", "value1", "groupX"); > cache.put("key2", "value2", "groupX"); > cache.flushGroup("groupX"); // this would evict both key1 and key2 > as they belong to groupX > > For more details, you can have a look at [1]. > > I've looked at the Infinispan's roadmap/JIRA, but couldn't find a > single trace of this feature mentioned anywhere.

On 3 Dec 2009, at 10:42, Galder Zamarreno wrote: > > > On 12/03/2009 11:38 AM, Galder Zamarreno wrote: >> >> >> On 12/01/2009 06:48 PM, Mindaugas Žakšauskas wrote: >>> Hi there, >>> >>> I am in process of reviewing Infinispan as, among other things, a >>> replacement of OSCache library we currently use. So far, it looks very >>> promising project - well done, guys! >>> >>> Anyway, one of the features we heavily rely on seems to be missing. >>> The feature is called "grouping", allowing to "bind" multiple >>> components and possibly flush them even without knowing of their keys. >>> E.g.: >>> >>> Cache cache = ....; >>> cache.put("key1", "value1", "groupX"); >>> cache.put("key2", "value2", "groupX"); >>> cache.flushGroup("groupX"); // this would evict both key1 and key2 >>> as they belong to groupX >>> >>> For more details, you can have a look at [1]. >>> >>> I've looked at the Infinispan's roadmap/JIRA, but couldn't find a >>> single trace of this feature mentioned anywhere. > > Note also that I don't think you're the only one wanting to do this. > Brian Stansberry, AS Clustering lead, wants something similar so that an > http session that is stored into Infinispan can be treated as a group > bearing in mind that a session contains a several k,v pairs. For different reasons. Brian's using AtomicMaps to gain "coarse locking and fine replication" characteristics of the AtomicMap - not the "group-flushing" effect.

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I haven't tested this but maybe you can put key1 and key2 into an org.infinispan.atomic.AtomicMap? I.e. AtomicMap<String, String> map = AtomicMapLookup.getAtomicMap(cache, "groupX"); map.put("key1", "value1"); map.put("key2", "value2"); // I know these 3 lines above work

And then... cache.evict("groupX"); // I dunno whether this line would work but if it did, it might do what // you're after.

You can find examples of AtomicMap usage in the Infinispan testsuite.

Hmmm, you talked to Manik already then. Did he mention anything about AtomicMap?

Brian Stansberry, AS Clustering lead, wants something similar so that an http session that is stored into Infinispan can be treated as a group bearing in mind that a session contains a several k,v pairs.

> Correct me if I'm wrong, but aside from AtomicMap specifics, this is > essentially a Map of Maps, isn't it? Which makes this approach similar > to what Sanne was offering a couple of emails ago. Not really - AtomicMaps allow for "group-level" locking.  So the entire entry is locked for write if you are updating any single key in the AtomicMap (hence the name). AtomicMaps also have another characteristic that they expose Deltas for replication to reduce network traffic.

Interceptors are pluggable - both via XML and via configuration, as well as at runtime.  When I mentioned these, I was suggesting that you maintain some metadata in the cache, which acts as 'group information'.  But this would require your deducing the group name on the fly (perhaps a function of the key used?)  If the group name has to be explicitly passed in then this approach wont work.

But anyway, lets think about why you need such "grouping" in the first place.

separately in the cache but still maintain relational knowledge?  If so, the approach to doing this is the JPA-like API [1] which will maintain references for you, cascade removals, etc.

And if you do wish to help build this, it would be much appreciated. :)

> That's more or less how OSCache grouping feature works. Does it sound > like a sensible Infinispan scenario? Yeah this can be tricky.  Like you said, evicting a group should cascade, and this would mean some "special treatment" for such a group entry.  And as you said, many other components would need to be aware of this (distribution, eviction, cache stores and loaders, marshalled value interceptors) so it is pretty intrusive.

I am assuming you have modelled your data as POJOs with references to one another?

Hi Galder,

> Brian Stansberry, AS Clustering lead, wants something similar so that an > http session that is stored into Infinispan can be treated as a group > bearing in mind that a session contains a several k,v pairs. I think the approach recommended by Sanne or you is sufficient enough to achieve such a functionality - one doesn't need to associate session data primitives (key-values) against many different sessions.