Hi, On 6/14/07, Thomas Mueller <[EMAIL PROTECTED]> 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
