[infinispan-dev] Entry grouping feature

[Manik Surtani]

On 3 Dec 2009, at 15:40, Mindaugas Žakšauskas wrote:

> Hi Galder,
> 
> ..and thanks for your reply. My comments are between your responses.
> 
> On Thu, Dec 3, 2009 at 10:38 AM, Galder Zamarreno <galder at redhat.com> wrote:
>> 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
> 
> To be pedantically precise, I had to enable batching in cache
> configuration for this to work - but that's just a minor detail.
> 
>> And then...
>> 
>> cache.evict("groupX");
>> // I dunno whether this line would work but if it did, it might do what
>> // you're after.
> 
> 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.

So very different from Sanne's approach, but still not one that would help you.

> I still don't see how it would be possible to have the same cache
> entry associated to multiple groups without duplicating same data
> across different maps and adding some not-so-nice hacks to
> flush/update such an entry.
> 
>> You can find examples of AtomicMap usage in the Infinispan testsuite.
> 
> I had a look at the tests in org.infinispan.atomic package but most of
> the tests were confined within testing a single map (e.g. whether
> fresh AtomicMap is empty, whether it retains values, etc.). Couldn't
> find any other usages of AtomicMap outside of this test package,
> though.

Used in the 'tree' module, but that is irrelevant.  :)

> 
>> Hmmm, you talked to Manik already then. Did he mention anything about
>> AtomicMap?
> 
> No, he didn't. The only thing he mentioned was interceptors; I got an
> impression this being some sort of pluggable thing. Again, I might be
> wrong.

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.  Is it to maintain relationships between data elements?  E.g., represent an object graph (Person has an Address which has PostCode, etc) and you wish to store each "entity" 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.  :)

Cheers
Manik

[1] https://jira.jboss.org/jira/browse/ISPN-24


>> 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.
> 
> 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