[infinispan-dev] conflicts resolution in DeltaAware

[Sanne Grinovero]

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.