Hi Marcel > no, you would only use a small number like 8. this is similar to how other > concurrent data structures work. e.g. the ConcurrentHashMap does not > have a single field for the size. it keeps the size per segment and therefore > allows updates to happen concurrently on different segments.
Don't these data-structures use locking for each segment to ensure consistency? How would you ensure that the same problem doesn't occur on the per-segment mod count then? AFAIU, without locking we only reduce the probability of the problem happening. Is that a satisfactory solution? Regards Julian On Tue, Feb 25, 2014 at 8:42 AM, Marcel Reutegger <[email protected]> wrote: > Hi, > >> maybe I don't understand - but you need to sync anyways when you write >> ACLs. or when do you detect collisions? the permission store itself is >> a problem for concurrency, as sparse modifications are consolidated in >> 1 place. so even if 1 node updates ACLs on /content/foo and the other >> on /content/bar, both need to update /<permissionstore>/everyone. > > but in most cases these updates could happen concurrently, at least with > the DocumentNodeStore (aka MongoMK). but the update on the mod > count causes a conflict. AFAIU the rest of the update is usually > non-conflicting. > the permission hook distributes the access control information into buckets > under /<permissionstore>/everyone. > >> > so, what if we replace the single mod-count property with multiple >> > properties? based on the hash of the modified access control entry >> > you would update one of them. this would at least allow some concurrent >> > updates. >> so, if I have 1mio ACLs if have 1mio modcounts? > > no, you would only use a small number like 8. this is similar to how other > concurrent data structures work. e.g. the ConcurrentHashMap does not > have a single field for the size. it keeps the size per segment and therefore > allows updates to happen concurrently on different segments. > >> as I said, if we could expose a revision number or content hash of >> subtrees, the modCount is not needed. >> or we disable the memory ACL cache completely on clustered environments. > > what is the performance impact if we do that? > > regards > marcel
