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
