jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: AccessManager Question.
Date Thu, 05 Mar 2009 11:41:33 GMT
Ok, thanks all makes sense.

On a related note, upgrading AccessManager to 15

Question:
Is there a better way to make Jackrabbit IoC friendly than extending  
RespositoryImpl and replacing class.newInstance() methods with  
injector.getInstance() (Guice10) ?


Background:

I notice that 1.5 has change the structure of the access manager and  
the way in which sessions startup.

The application I am working on uses Guice to perform Constructor IoC.
This causes problems with Jackrabbit as it does class.newInstance()  
which bypasses all chance of constructor IoC.

In 14 I was able to extend RepositoryImpl and override the various  
create* methods.
eg createSessionInstance().

unfortunately in 15 the structure under XASessionImpl has changed and  
it looks like its no longer possible to override createAccessManager  
as it depends on rep.getFileSystem() and rep.getSecurityManager() both  
of which are package private.

Also if I try and override getSecurityManager() from the  
RepositoryImpl I find that its WokspaceInfo is similarly package  
protected.

In 15 the RepositoryInfo.WorkspaceInfo class is preventing me from  
getting an Instance of an IoC'd JackrabbitSecurityManager

I could just put it in a o.a.j.core but that will eventually play  
havoc with Java7 and or OSGi.


Ian

On 5 Mar 2009, at 11:21, Stefan Guggisberg wrote:

> hi ian
>
> On Thu, Mar 5, 2009 at 2:26 AM, Ian Boston <ieb@tfd.co.uk> wrote:
>> I have an AccessManager implementation that uses its own session to  
>> get
>> properties (ACL) on nodes and the parents of nodes that it is  
>> controlling.
>>
>> I get lots of
>> WARN: overwriting cached item b38c5119-2aa2-4e08-b4bf-41dd1720c197
>> (2009-03-03 17:10:59,740
>> TP-Processor3_org.apache.jackrabbit.core.ItemManager)
>>
>> I think this is because the ItemManager is checking with the  
>> AccessManager,
>> which is adding the item to the cache in ItemManager, and when the  
>> current
>> thread returns to ItemManager to put the item in...... its already  
>> been
>> pulled in by AccessManager.. hence the warn.
>
> that's correct.
>
>>
>> I am using 1.4.8, I couldn't find anything in jira to help.
>>
>> So, my questions:
>>
>> If I want to store ACL's on the nodes, can I use the same session  
>> as is
>> accessing the node, or do I have to create a second session just for
>> accessing the ACL's ?
>
> i would recommend using a dedicated session for accessing the ACL's.
>
>>
>> Will creating a second session per AccessManager have a performance  
>> impact ?
>
> a session is not light-weight and does have a considerable memory  
> footprint.
> assuming you've got enough jvm heap it shouldn't cause performance  
> issues.
>
> you might try to use a shared ACL reading session for multiple  
> AccessManagers
> in order to reduce memory consumption. we've tried to make read-only  
> sessions
> thread-safe, however this has only been a best effort. you might still
> run into the
> occasional concurrency issue under heavy load. our 'official' stamenet
> is: a Session
> is not thread-safe.
>
> cheers
> stefan
>
>>
>> Ian
>>


Mime
View raw message