[infinispan-dev] conflicts resolution in DeltaAware

[Manik Surtani]

On 21 Apr 2011, at 11:10, Sanne Grinovero wrote:

> thanks for resuming this topic;
> some more thoughts:
> 
> 2011/4/20 Manik Surtani <manik at 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 at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org