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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org