You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2006/09/11 10:11:20 UTC
Session-local versioning component?
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
Re: Session-local versioning component?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 9/11/06, Tobias Bocanegra <to...@day.com> wrote:
> 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.
OK, sounds reasonable.
> 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 transaction.
Cool. Do you already have a plan on how to make that happen? Could the
"LocalItemStateManager for versioning" approach I was proposing be
used as an evolutionary step towards that goal?
The reason I'm raising this issue is that it seems to me to be the
least intrusive way to easily and cleanly support the "restore version
histories" use case.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Session-local versioning component?
Posted by Tobias Bocanegra <to...@day.com>.
hi,
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
transaction.
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 <ju...@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 >---