jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3933) potential improvements to membership storage
Date Tue, 02 Feb 2016 14:10:39 GMT

    [ https://issues.apache.org/jira/browse/OAK-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15128286#comment-15128286

angela commented on OAK-3933:


2) Avoid having to instantiate authorizables for declared membership checks

The easiest solution for this was having {{Group.isDeclaredMember(String id)}} as for the
internal evaluation the corresponding user/group is not needed anyway.
What you mention as possible solution would only be needed/helpful for {{Group.isMember}}
which takes transitive membership into account. For that latter we may consider using the
opposite approach: retrieve the group membership of the user/group passed as parameter and
check if the target group is included. For huge groups and/or heavily nested group membership
this most probably was the better approach as long as a given user/group is not member of
zillions of Groups.

> potential improvements to membership storage
> --------------------------------------------
>                 Key: OAK-3933
>                 URL: https://issues.apache.org/jira/browse/OAK-3933
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: security
>            Reporter: Julian Reschke
> Membership information of a group currently is stored as an unsorted set of IDs, spread
over multiple child nodes, using multivalued properties (of 1000 each).
> This content structure makes certain operations relatively slow:
> 1) Checking for declared membership
> When the authorizable to be checked is not a member, all child nodes need to be read
and examined (in the other case, checking stops when a match is found).
> 2) Checking for inherited membership
> The membership IDs do not reveal the type of authorizable. In order to check inherited
membership as well, the authorizable with the given ID needs to be read from storage in order
to check the type.
> Below are a few ideas how this might be improved (however, the change of structure would
require a mgiration step).
> 1) Avoid having to read all child nodes to check declared membership
> Assuming an alphanumeric ID structure, this could be achieved my modifying the structure
like that:
> - as before, start with a single node
> - when a new member needs to be inserted and the candidate node is already full (has
1000 entries), create a new child node named after the first character of the authorizable
> - when this "level 1" member is full, start using "level 2" members and so on
> (assuming the ID structure is suitable for that, otherwise a different hash could be
> To check for membership, we wouldn't need to read *all* child nodes, but only those where
the node name is a prefix match of the ID.
> 2) Avoid having to instantiate authorizables for declared membership checks
> - put limited type information into the stored IDs, such as "u" and "g" prefixes; that
way the code could identify authorizables that are users and avoid having to instantiate them
> (this assumes that an ID that refers to a user will never refer to a group in the future)

This message was sent by Atlassian JIRA

View raw message