Re: [infinispan-dev] conflicts resolution in DeltaAware

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.