[
https://issues.apache.org/jira/browse/JCR-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2968:
-------------------------------
Attachment: 0001-JCR-2968-Add-an-option-to-read-the-Clustering-Journa.patch
OK, I see why this would be useful, but I think the implementation is a bit
confusing.
The point, if I understand correctly, is to update the LOCAL_REVISIONS table on
the master database, but use the replicated slave database for everything else.
Thus to me it would feel more natural if it was the data source for the
LOCAL_REVISIONS table instead of all the other access that's configured with an
extra new parameter.
Also, it seems that we should have some explicit flag to enforce the read-only
requirement of such deployments.
The attached patch implements these suggestions by introducing a
"localRevisionDataSourceName" configuration option and an explicit "readOnly"
flag to accompany it. The read-only status is automatically set if a local
revision data source is specified. A read-only journal will throw exceptions
for any write attempts on that cluster node.
Would this work for your use case?
> 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
> Reporter: Christian Stocker
> Fix For: 2.3.1
>
> Attachments:
> 0001-JCR-2968-Add-an-option-to-read-the-Clustering-Journa.patch,
> 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
