Hi, On Mon, Feb 24, 2014 at 2:17 AM, Marcel Reutegger <[email protected]> wrote: >> so what the cache does, it checks if the memory representation is >> still on par with the one in the store by comparing the mod-count. if >> there is another way to do this, I'm more than happy to know. > > the main problem currently is that this requires an implementation to > serialize writes to the permission store for a given principal. 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.
> 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? 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. or we once again think of a better/faster strategy to collect the ACLs and abandon the permission store idea. OTOH, I think that ACL modification are relatively rare compared to other updates. regards, toby
