[
https://issues.apache.org/jira/browse/JCR-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2968:
-------------------------------
Fix Version/s: (was: 2.3.1)
Bart, I like your idea in general as it's more flexible than the original one.
Anyway, I'm a bit concerned about essentially duplicating the entire journal
configuration for the "slave journal".
Since the only thing we're really overriding here is the handling of the local
revision table (and through that the janitor mechanism), I wonder if it would
be cleaner to refactor the relevant code out of the normal journal handling
(sync, update, etc.) and add a separate configuration mechanism for specifying
how and where the local revision should be stored. If such configuration is not
present, we could for backwards compatibility fall back to the current behavior.
It seems like this still needs some thought, so unscheduling from 2.3.1.
> 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
