jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3688) Optimize MembershipCache invalidation
Date Mon, 04 Nov 2013 13:32:21 GMT

    [ 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

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

View raw message