hi daniel,

On 4/28/06, Daniel Hagen <[EMAIL PROTECTED]> wrote:
Hi,

I hope this list is the right place to ask, if not, just don't answer ;-)

I have built a custom access manager which uses hierarchical path based
access control lists to determine wether a subject has access to a given
object (meaning node).

Basically, what I do in the AccessManager is:

[...] = amContext.getHierarchyManager().getPath( id ).getPathElements();

Then I iterate over the returned path elements and match them with the
authenticated subject's permissions.


However I noticed an immense performance impact (about 500% in a search)
resulting from this because every getPath() call leads (in the end) to a
load() call in the PersistenceManager.

Unfortunately the caching mechanisms of jackrabbit (or any caching
mechanism) won't help me in the given scenario (a lot of nodes which are
accessed infrequently, frequent insertions into the repository).

I would load the itemId -> path assignment at startup but as I understand
the architecture of the AccessManager it is neither possible to get a list
of all item ids nor is it possible to be notified when a node is inserted to
keep the cache up to date.

So I am quite stuck at this point.

Enough talk, now the questions: ;-)

Is there a cheaper way to get a path for an ID (I can already guess the
answer to that one)?
Is there any way to achieve the aforementioned itemid/path loading in a
custom accessmanager?
Am I missing some other possibility?

amContext.getHierarchyManager() does return an instance of
o.a.j.core.CachingHierarchyManager which does, as its name implies,
maintain a cache of id->path mappings which should prevent excessive
path building. can you provide a simple test case that demontrates your
issue?

cheers
stefan


Thanks a lot!

Daniel


Reply via email to