jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: [jr3] Unified persistence
Date Wed, 17 Feb 2010 16:00:08 GMT
On Wed, Feb 17, 2010 at 16:33, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> In addition to the search index (that deserves it's own thread), we
> have various different mechanisms for persisting repository
> information:
>    persistence managers for node and property states
>    data store for binary properties
>    journal for cluster synchronization records
>    file system abstraction for various minor things like:
>        custom_nodetypes.xml for registered node types
>        ns_reg.properties for registered namespaces
>        rootUUID file for the root node UUID (essentially a constant)
>        workspace.xml for workspace configuration
>        locks for open-scoped locks
> Most information that we store in the repository is duplicated in at
> least two of these locations. Reducing the amount of different storage
> formats and mechanisms we use would make a lot of things easier.
> Ideally we'd have a single clustered persistence layer that we could
> use for all of these things (and the search index).
> How can we achieve something like that?

I think a good idea (and I guess this is what you have in mind) would
be to have a lower-level persistence API that is journal/cluster-aware
and allows for all the basic node and property storage. But all the
type constraints, versioning etc. JCR features are only done on a
higher level. This could make it easier to use the lower-level
persistence for things like the above w/o necessarily breaking JCR
contracts. An import/export on this level could also be used for fast
and full-coverage backups and dumps.

These parts could then be made accessible via the JCR API selectively,
but eg. read-only (for those where JCR defines a separate API, egg.
namespace registry, node types).

The main advantage however, would be that of more flexibility in
writing the persistence layer and optimizing it for performance.
Currently many things are entangled (eg. child node entry list of
nodestates, see JCR-642) across many layers.


Alexander Klimetschek

View raw message