[infinispan-dev] Entry grouping feature

[Mindaugas Žakšauskas]

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.

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.

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

> 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