jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: svn commit: r1458234 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/core/ oak-core/src/main/java/org/apache/jackrabbit/oak/kernel/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/version/ oak-core/src/main/java/o
Date Fri, 22 Mar 2013 17:25:04 GMT
hi jukka

sure... you may want to look at the items accessed for a
regular cq page request in order to come up with a realistic
scenario and then scale that up to a huge repository.
however, please keep in mind that if we are really going to move
the permission evaluation below the tree level, we
a) need to have an efficient way to determine the path of a
    given node state (or it's immutabletree representation)
    as our permission evaluation basically is path-based
b) may end up with different caches for different set of
    principals (as discussed during the last okathon).

kind regards

On 3/22/13 4:41 PM, Jukka Zitting wrote:
> Hi,
> On Fri, Mar 22, 2013 at 5:01 PM, Angela Schreiber<anchela@adobe.com>  wrote:
>> quite frankly: IMHO the bigger impact on memory usage is
>> that afaik we currently load all parent states which most likely
>> will not be all accessed by the oak/jcr API calls.
> I don't think so. The number of intermediate nodes that need to be
> traversed to access distinct N nodes is O(log N) in a typical
> hierarchical structure. In contrast the number of paths that would
> have to be kept around is O(N).
> That should be easy to verify with a benchmark. I'll see if I can come
> up with one.
> BR,
> Jukka Zitting

View raw message