jackrabbit-dev mailing list archives

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

    [ 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

View raw message