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: Propagation of Session auto refresh behaviour to e.g. UserManager
Date Tue, 06 Aug 2013 09:23:32 GMT
hi jukka

IMO the approach in the namespaceregistry is something different:
in that case you have a different write-root that needs to make
sure that the root (and the editing session) gets updated once
the changes are persisted.

but in this case as michael explained the setup is that one session
should be informed about modifications made by another session.
this works for all operations that are 'attached' to the SessionDelegate
but the refresh doesn't work for those classes that are just associated
with the Root (such as e.g. the UserManager which btw. makes transient
modifications on the root associated with editing session. the read-write
trick doesn't help here). btw: it's one of the fundamental design decisions
for the oak security code to build the implentations on top of the OAK API.
this contrasts to the Jackrabbit setup which lead to a lot of hacks and
at the end didn't work very well.

so, what we would need is a refresh on the Root instead of just refreshing
upon session access. i just discussed this with Michael and we both fear
this will open a huge can of worms...

what we are basically trying to do is to changing one of the fundamental
concepts of OAK (refresh only occurs if manually triggered), which IMHO
needs a careful analysis of the consequences.

let's discuss that in the call this afternoon.

On 8/6/13 10:41 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig <mduerig@apache.org> wrote:
>> We might have similar issues with other entities tied to a session like
>> PrincipalManager, VersionManager, ... Basically all (indirect) callers
>> SessionDelegate#getRoot() are suspect... and that's quite a list.
>We sorted out a good pattern for doing stuff like this already with
>the namespace registry. Basically:
>a) When making transient changes or reading information that can come
>from an earlier repository snapshot, use sessionDelegate.getRoot() so
>that you see the exact same state as the rest of the session.
>b) When persisting changes directly to the repository or reading from
>the latest repository state without interference from transient
>changes, use sessionDelegate.getContentSession().getLatestRoot() and
>follow up with a session.refresh(true) to force the rest of the
>session to keep up.
>The abstract method pattern in ReadWriteNamespaceRegistry (or
>something similar) can be used to avoid a direct oak-jcr /
>SessionDelegate dependency.
>That pattern should cover the needs of the UserManager and other
>places without the need to manage the states of multiple independent
>Root instances.
>Jukka Zitting

View raw message