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(a)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(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