[infinispan-dev] conflicts resolution in DeltaAware

[Galder Zamarreño]

On Apr 11, 2011, at 2:31 PM, Mircea Markus wrote:

> 
> 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.   

Hmmmm, but can't we have the best of both worlds? The reason I ask myself is cos OGM is gonna use this for storing collections that are likely to change often. So, if you have a collection of 1000 elements and you add one, you have to replicate those 1001 elements - that's not gonna scale well.


>> 
>> Sanne
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache