[
https://issues.apache.org/jira/browse/JCR-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813018#comment-13813018
]
Tobias Bocanegra commented on JCR-3688:
---------------------------------------
bq. IMO the onMemberAdded/onMemberRemoved should be only be called after having
successfully modified the list of members of a given Group... in the patch the
pending changes is being notified before
right, but then the invalidation needs to go into the UserManagerImpl, which I
wanted to avoid. in the worst case, there is more invalidated than required.
bq. second, i think the critical part is concurrently modifying group
membership and having colliding modifications for the same user/group. there
should be tests verifying that this doesn't cause regressions.
in the worst case, there is more invalidated than required.
bq. how do you plan to deal with such a situation (someone might maliciously
try do this)?
but he would also need to generate many authorizables, transiently. so it might
be enough to to mark pending memberships of new transient authorizables.
> Optimize MembershipCache invalidation
> -------------------------------------
>
> Key: JCR-3688
> URL: https://issues.apache.org/jira/browse/JCR-3688
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, security
> Reporter: Tobias Bocanegra
> Assignee: angela
> Attachments: jcr3688-r1538062.patch
>
>
> The current membership cache is invalidated entirely for every membership
> change, i.e. entries that are not affected by the change are invalidated.
> systems with many authorizables tend to have a full membership cache will
> suffer from frequent invalidation.
> The way the cache is invalidated today is based on synchronous observation
> event. From the event alone it will be very inefficient to figure out all
> membership changes without extra state keeping. A more direct approach is to
> invalidate the membership changes directly in the cache based on the
> Group.addMember(), Group.removeMember() and Group.remove() methods. If the
> user manager is not autosave enabled, the invalidation needs to be delayed
> until the save call.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
