[
https://issues.apache.org/jira/browse/JCR-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125668#comment-13125668
]
Bart van der Schans commented on JCR-2968:
------------------------------------------
Hi Jukka, Christian,
I agree about the code duplication. So I'm merging Christian's and mine
solution to the "run jr on a db slave" issue.
The current "logic" is:
1. With the "normal" (old) cluster/journal configuration everything works as it
always did
2. If the readOnly flag (from the patch from Christian) is set to true, the
FileRevision is used; unless
3. An explicit "InstanceRevision" (database connection) is configured
Number 2 is what I proposed and number 3 is the proposal of Christian.
To achieve this I have:
- split out the DatabaseRevision part from the journal code
- split out the DatabaseConfig from the journal code in o.a.j.core.util.db so
it can be reused by the DatabaseRevision (and maybe other parts of the code as
well)
- added the readOnly property
- use a FileRevision when the readOnly property is set
(see https://github.com/schans/jackrabbit/commits/JCR-2968 , still work in
progress)
For the last bit I would like your opinions on how to specify the database
instance revision connection. I'm thinking about adding an "InstanceRevision"
directly as child of the "Journal" config element in the repository.xml, but it
can also be a child of the Cluster element itself. The InstanceRevision element
will the same db parameters as the Journal element.
Wdyt?
> Add an option to read the Clustering Journal from a different source than the
> rest of the clustering info
> ---------------------------------------------------------------------------------------------------------
>
> Key: JCR-2968
> URL: https://issues.apache.org/jira/browse/JCR-2968
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: clustering, jackrabbit-core
> Affects Versions: 2.2.9
> Reporter: Christian Stocker
> Assignee: Jukka Zitting
> Labels: patch
> Attachments:
> 0001-JCR-2968-Add-an-option-to-read-the-Clustering-Journa.patch,
> database-slave-local-revision-on-file.diff, patch_commit_2eed44310e71.patch
>
>
> This patch adds the possibility to read (but not write) the Cluster JOURNAL
> from a different source than the rest of the cluster information. This makes
> it possible to setup a master/slave DB setup, where everything cluster
> related is read from the slave, but writes to the master. It reads the actual
> data also from the slave and assumes that this jackrabbit instance never does
> any writes (except for updating the cluster index position in the DB). We
> have to read the Cluster Journal from the slave to guarantee a consistent
> state
> More info why and how is here
> http://blog.liip.ch/archive/2011/05/04/how-to-make-jackrabbit-globally-distributable-fail-safe-and-scalable-in-one-go.html
> I didn't write any tests yet, if you can point me, where I should add them,
> I'll gladly do them.
> Would be great, if we could integrate that in any of the future Jackrabbit
> releases.
> It's of course fully backwards compatible, nothing changes, if you don't
> sepcify
> <param name="dataSourceNameJournalRead">
> in repository.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
