On 21 Apr 2011, at 11:10, Sanne Grinovero wrote:
thanks for resuming this topic;
some more thoughts:
2011/4/20 Manik Surtani <manik(a)jboss.org>:
> I think changing the merging interface won't solve your problem since as others
have pointed out, the AtomicMap is locked based on its key. So you won't be able to
have concurrent updates to the AtomicMap anyway.
I didn't delve yet into how Infinispan is managing locking, but it
seems every time we talk about it I get confused; sorry it seems my
assumptions don't match the implementation.
I have read
http://community.jboss.org/wiki/LockingandConcurrency
which states that Infinispan by default acquires locks lazily, i.e. at
transaction(batch) boundaries, possibly failing at this point if
that's not possible.
These are remote locks. Local locks are eager.
So assuming that OGM is never eagerly locking the AtomicMap, I'm
going
to assume that the worst case the owner of such an atomic map would be
to receive two different update statements, one A'->A'' and one
A'->A'', so the owner should be able to figure out a different delta
to apply A'->A''' , if that's possible to apply both without
conflicts.
So 2 threads on the same VM would compete for the same lock.
Of course I'd expect the AtomicMap being locked during the
transformation - very briefly on the owner side only - but I don't see
how the two delta commands are generating two lock commands, unless
we're talking about eager locking.
>
> Mircea's suggestion of a Cache instance instead of an AtomicMap is _conceptually_
correct, but practically, don't do it! One Cache instance per entity is way
overkill.
Yes I figured that, wasn't going to try it; BTW it would present the
same problem recursively as I would need to track them..
>
> Perhaps what you need is a different type of grouping structure, perhaps a
FineGrainedMap, similar to an AtomicMap, which is locked based on a combination of map
name and key accessed within the map.
>
> Would need to think about how this works with the rest of the locking code...
Yes please :)
I'm surprised nobody else expects this from an AtomicMap, nobody asked
for something similar during the relatively longer experience with
JBoss Cache using the Tree API?
JBoss Cache (and the Tree API) was designed specifically with coarse locking and people
expected and wanted this behaviour for attributes in tree nodes. AtomicMaps were built to
support the tree API in Infinispan and hence the same semantics.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org