jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Propagation of Session auto refresh behaviour to e.g. UserManager
Date Tue, 06 Aug 2013 09:21:29 GMT

On 6.8.13 10:41, Jukka Zitting wrote:
> Hi,
> 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 of
>> 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.

This is not sufficient for the current case however unless we add a 
session refresh for every call to SessionDelegate.getRoot().

Furthermore the underlying (somewhat implicit) assumption back then was 
sessions being stable (i.e. no auto refresh) such that the returned root 
and trees retrieved from it can be cached. This is now not the case any 
more and might render many such optimisations invalid.


> 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.
> BR,
> Jukka Zitting

View raw message