[infinispan-dev] Entry grouping feature

[Mindaugas Žakšauskas]

Hi Sanne,

Thanks a lot for your input. Your approach is really interesting, I'd
call it a "declarative grouping". However, I think it is not
sufficient because groups in my case are not deterministic.

A typical, yet simplified, scenario: bunch of objects (A1, A2, ...,
An) are cached/tied to some other object (B). Current code does it by
dynamically adding them to a group "B_id", where "id" is the unique
identifier of entity B. If B is destroyed, it can then can recursively
destroy all As.

But hey, there's more! If an entity is cached against more than one
group, it all ends up in duplicating information across multiple Cache
instances. Apart from increased space requirements, this also leads to
royal pain when updating/flushing such an entry.

Again, I think this is very reasonable approach when groups are
somewhat static or specialized, as you said. Sadly, this is not always
the case :(

Still waiting for comments on the feasibility of such a feature...

Regards,
Mindaugas

On Tue, Dec 1, 2009 at 6:25 PM, Sanne Grinovero
<sanne.grinovero at gmail.com> wrote:
> 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 at gmail.com>:
>> 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/Cache.html
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev