Hi Marcel, On Wed, Feb 19, 2014 at 8:45 AM, Marcel Reutegger <[email protected]> wrote: > I ran into a case where multiple sessions on different cluster nodes > create access control entries for the same principal. admittedly, this > was done in a test and may not be too likely reality, but it showed > a problem with the permission store and how clustering on mongo > works. > > it seems the node for the principal in the permission store is updated > whenever there is a change. that is, I see frequent changes on the > rep:modCount on /jcr:system/rep:permissionStore/crx.default/everyone > even when there are no other changes on that node. I might be misreading > the data, but I was wondering what the purpose of this rep:modCount > is? this property is used for controlling the memory cache of the permissions of a principal. it should only change if you alter an ACL that involves that principal. Especially for the 'everyone' principal, it totally makes sense to cache the permissions as this principal is involved in so many ACLs.
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. initially I thought I could use the content-hash of that subtree - but this is IIRC specific to the MKs. and the revisions are specific to the document stores and not localized. > with the DocumentNodeStore on MongoDB in a cluster, the rep:ModCount > can become a problem when there are concurrent updates for a principal. > within one DocumentNodeStore instance there is a fallback similar to the > pessimistic locking in the segment implementation, but clustered > DocumentNodeStore > instances do not have a lock mechanism to serialize writes across the > complete cluster. > this is considered too expensive. in the clustered case, the commit is simply > retried a number of times but at some point the save call fails if retries > are still > not successful. ok. so what's the best way to determine stale cache content? another approach would be to store the entire permission data of a principal in 1 large property (eg json serialized). but then you'll see update of that property whenever you change the permissions of a principal. would that perform better? regards, toby
