[infinispan-dev] Entry grouping feature

[Manik Surtani]

On 4 Dec 2009, at 11:15, Mindaugas Žakšauskas wrote:

>> 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.
> 
> I was thinking of similar approach myself: each key would be always
> wrapped into a "group decorator" object. Each such decorator would
> then be maintained in a separate {group name => list of keys} map.
> This might be doable assuming there are facilities to efficiently
> maintain such a map.
> 
> By saying "efficiently maintain" I mean, for example, removing group
> map entry when gets evicted from LRU cache because of idleness.
> Moreover, this has to be independent from cache specifics (LRU vs
> LFU), clustering and so on.
> 
> 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.

> 
>> But anyway, lets think about why you need such "grouping" in the first place.
> 
> I have deliberately tried to avoid burdening this mailing list with my
> own problems, but since you've asked :)
> 
> I have a large graph of computational-expensive objects (pieces of XML
> text) which I store in the cache. The algorithm traverses the graph,
> assembles necessary nodes in the right order and spits out the result.
> 
> There can be multiple invariants of same object in the graph, e.g.
> there can be different XML representations of "John Smith" profile.
> When caching all these different invariants, I put them under same
> unique group so if underlying object changes, flushing all of these
> invariant entries is a matter of calling a single method.
> 
> This is a very skimmed description; the whole thing can be much more
> complex, e.g.
> 
> A ==uses==> B ==uses==> invariant(A) ==uses==> invariant(B)
> 
> Current grouping functionality is just what I need and fits perfectly
> for the job. Maintaining separate caches for different objects/trees
> (or possibly using JTA) would add lots of unnecessary complexities to
> already complicated algorithm.

Yes, I can see how separate caches or atomic maps won't help you.

> 
>> 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.
> 
> Thanks for the pointer. My first impression by looking at the JIRA
> issue & the doc says this isn't entirely what I'm after - but I'll
> definitely have a deeper look.

It may not be what you are after, but it may "do the job".  I am assuming you have modelled your data as POJOs with references to one another?

> 
>> And if you do wish to help build this, it would be much appreciated. :)
> 
> Absolutely! But as I said, I'd need a bit of guidance and advice -
> e.g. where to stick the methods, what is the best way to achieve this,
> etc. I could probably start prototyping this and see how it goes.
> 
> Regards,
> Mindaugas
> 
> _______________________________________________
> 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