[infinispan-dev] conflicts resolution in DeltaAware

Mircea Markus mircea.markus at jboss.com
Mon Apr 11 08:31:21 EDT 2011


On 11 Apr 2011, at 13:14, Sanne Grinovero wrote:

> 2011/4/11 Mircea Markus <mircea.markus at jboss.com>:
>> 
>> On 8 Apr 2011, at 18:30, Emmanuel Bernard wrote:
>> 
>> Yes I think that would fit the bill. Let me give some more background
>> Background
>> In Hibernate OGM, we store collections in a single key essentially as a
>> Set<Map<String,Object>> ie as a set of tuples, esch tuple representing the
>> equivalent of one row of an association table in a relational database. The
>> reason for that is to be able to get the collection state by doing key
>> lookups. If we were to store each tuple of the collection in a separate key,
>> we would have no way to get the list of matching keys for a given collection
>> (unless you get a key with the list of keys for a collection but then you
>> are just moving the problem instead of fixing it.
>> 
>> Today, we reach scalability problems very quickly as we end up touching the
>> collection key every time one entity is added or removed from it. In a
>> relational database, this operation scale quite well as locks are acquired
>> on each tuple and not on the whole tupes for a given collection.
>> 
>> What we could do is:
>>  - use AtomicMap<UUID,Map<String,Object>> instead of Set<Map<String,Object>>
>>  - trick infinispan so that it believes that the atomic lock is held at the
>> atomic map key level rather than the atomic map as a whole.
>> 
>> Many operations could be done consecutively:
>>  - update k1 in T1 and k2 in T2 in concurrently
>>  - add k1 in T1 and remove k2 in T2 concurrently
>> etc
>> what would still fail is:
>>  - modify k1 in T1 and k1 in T2 concurrently
>> 
>> You'd get this by using a Cache<UUID, Map<String, Object>>, together with
>> fine grained replication.
> 
> Hi Mircea, could you elaborate on that? What is fine grained
> replication and how is that going to affect locking?
by fine grained I mean key based replication. The cache has fine grained/key based replication (i.e. you only replicate the changed key not the entire cache) and fine grained/key based locking. AM has fine grained replication but coarse grained locking - as it locks the whole Map on access. Seems to me that what you need is 
a Cache, rather than a AM for your use case.   
> 
> Sanne




More information about the infinispan-dev mailing list