hi, 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? 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. regards marcel
