[infinispan-dev] conflicts resolution in DeltaAware

[Mircea Markus]

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

> 2011/4/11 Mircea Markus <mircea.markus at jboss.com>:
>> 
>> 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.
> 
> Ok I need a Cache to get this semantics, but I can't create a new
> Cache for each new entity instance we store right? The UUID is the
> entity primary key, we need to be able to find the collection related
> to this specific UUID.
My understanding is that all the collections, as described by Emmanuel, are held in a single instance of AtomicMap<UUID,Map<String,Object>>, am I wrong? 
Indeed crating a Cache per Collection instance might be too costly.