[
https://issues.apache.org/jira/browse/JCR-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812827#comment-13812827
]
angela commented on JCR-3688:
-----------------------------
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*.
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.
third i would like to have tests for those cases where persisting the changes
on the group(s) fails (that could easily be achieved by making other transient
changes like e.g. adding a node at a location where the editing session doesn't
have the required permissions)... in this case the set on the cache might grow
without being cleared... how do you plan to deal with such a situation (someone
might maliciously try do this)?
> 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)
