On 15 Mar 2010, at 15:04, Thomas Müller wrote:
Hi,
wasn't the journal added to be separate from the persistence manager
implementation and allow for a fast exchange of master/slave node
information and latest revisions? Or is this separation not useful?
I'm not sure what the reasons for
Currently the journal (cluster journal and event journal) is stored
using a separate storage mechanism.
I think it should be stored using the 'normal' storage mechanism.
Advantages:
- Simplifies the architecture (specially for clustering)
- Events and node data are in the same transaction, which
Hi,
IIRC this would be inline with another discussion in the [jr3] arena, to
have a common low-level persistence upon which all the other parts of
Jackrabbit requiring some form of persistence (except logging and
configuration, probably) build.
In this context, I would think it to be a good idea
Hi,
(except logging
Yes, I think SLF4J is fine
and configuration, probably
Some information need to be available when the repository is
constructed, or at the latest when logging in: What storage backend to
use, and how to connect to the storage backend.
The rest of the configuration
Hi,
In case of cluster db journal, the hostname of db connection.
The hostname of the database (if a database is used) and the database
name needs to be known when creating the repository object. Storing it
in a 'repository.xml' file is possible, but it's just an unnecessary
indirection. If you