jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Session-local versioning component?
Date Mon, 11 Sep 2006 12:13:06 GMT
the reason for this was that the version manager was designed to be
able to store in whatever backend. but nowadays, i think that we won't
change this anymore and even move the versions more into the content
structure. my plan is to use the 'normal' item manipulations for the
versions once the version workspace can be transparently mounted and
get rid of the virtual item states completely. having this, the
versioning operations would be part of the normal changelog of the

i only see a reorg in this respect, when we get rid of the virtual
item states and support a general mounting of item state providers on
the item manager level.

regards, toby

On 9/11/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> Prompted by the architectural problems Nicolas ran into with restoring
> version histories I've recently been looking at the VersionManager
> implementation, trying to look for ways to make the design more
> flexible for such extensions.
> The key problem I've identified is that the VersionManagerImpl uses a
> SharedItemStateManager directly for reading and writing versioning
> information. This forces the implementation to bend quite a lot for
> example to properly implement observation. A good example of this
> effect is the DynamicESCFactory class within VersionManagerImpl that
> makes all versioning operations synchronized just to enable firing of
> correct observation events.
> At first I thought that this bending was caused by a problem in the
> EventStateCollectionFactory interface, that it shouldn't need a
> reference to the source session, but after enough experimenting I
> started wondering why we don't have a session-local versioning
> component that would make both observation and a number of other
> things quite a bit cleaner.
> As a background, here's the stack of ItemStateManagers for a normal workspace:
>     * SessionItemStateManager: associated with a session, handles the
> transient space
>     * LocalItemStateManager: associated with a session, handles
> observation, etc.
>         * XAItemStateManager: subclass of LocaltemStateManager, adds
> transaction support
>     * SharedItemStateManager: associated with the workspace persistence manager
> The versioning implementation works directly on the
> "SharedItemStateManager" level. There is no need for the highest level
> with versioning since versioning operations are not transient, but
> adding a "LocalItemStateManager" level to versioning would likely
> simplify the design, and might even remove the need to globally
> synchronize versioning operations.
> Incidentally, there already is a "XAItemStateManager" level
> implemented in the XAVersionManager class, so making this change
> shouldn't introduce too big problems.
> Any thoughts?
> BR,
> Jukka Zitting
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development

-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

View raw message