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.mar...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev