On 6.8.13 10:41, Jukka Zitting wrote:
Hi,
On Tue, Aug 6, 2013 at 11:24 AM, Michael Dürig <mdue...@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.
Michael
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
