jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Next Generation Persistence
Date Fri, 15 Jun 2007 09:44:59 GMT
Hi,

On 6/14/07, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
> I like to better understand the reasons for NGP. I found the following
> issues in JIRA, but I think most of those problems can be solved even
> without NGP. Are there any other issues to consider (and issues
> without JIRA entry)?

The reason I started drafting the NGP proposal was to come up with an
architectural roadmap for something like the next five years in
Jackrabbit. The current architecture (as summarized in [1] and [2])
already has quite a lot of history behind it and I think we are seeing
some new use cases that the current architecture doesn't support very
naturally. For example the clustering feature is more like an add-on
than an integral part of the repository. Another example is bundle
persistence that has to go through extra trouble (has it's own caches,
converts between bundles and item states, etc.) to fit the
PersistenceManager API.

[1] http://jackrabbit.apache.org/doc/arch/overview.html
[2] http://jackrabbit.apache.org/doc/arch/operate/index.html

The actual model I came up with, NGP, is just one possible approach,
based mainly on the following goals:

* Focus on read performance, i.e. massive concurrency (no locking) and
caching (no invalidation) opportunities for typical read loads
* Transactions and clustering as core features, with no need for
external databases
* Hot backup and point-in-time recovery as core features

I'm open to debating whether these really are the goals that we want to achieve.

Another important reason why I wanted to start this kind of an
architectural discussion is that it'll open us to new kinds of
solutions that we can start implementing already in the current
architecture; the data store concept being a prime example of such
progress.

> What do you think about using the same connection for versioning and
> regular access? I know it requires refactoring, and a new setting in
> repository.xml. Anything else?

This is another case where the current architecture limits our
options. The persistence model is best suited for a case where each
workspace and the versioning store have their own independent backend
stores. It would be interesting to explore how far we can go with
incremental changes.

BR,

Jukka Zitting

Mime
View raw message