Re: [infinispan-dev] conflicts resolution in DeltaAware

2011/4/11 Mircea Markus <mircea.markus(a)jboss.com&gt;: > > 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?

Sanne