[
https://issues.apache.org/jira/browse/JCR-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Hendriks updated JCR-1087:
----------------------------------
Attachment: JCR-1087-v2.patch
Hi all,
Unfortunately I've been inactive for a while but now i've more time to work on
Jackrabbit which is good :). I created a second patch for this issue which
also addresses the upgrade scenario that Dominique mentioned:
- Added the LOCAL_REVISIONS table to the create scripts (*.ddl)
- Added InstanceRevision interface
- The InstanceRevision is now retrieved through the Journal instance
- Added logic to the DatabaseJournal to (i) migrate to a db based
InstanceRevision,
and (ii) start a janitor thread for cleaning up old cluster revision entries
I've tested the patch only on MSSQL, MySQL and Oracle, because I don't have
access to the other databases.
I don't really like the solution for the upgrade scenario (a ddl is scanned for
the line that creates the LOCAL_REVISIONS table), but I like the alternative of
having twice as many .ddl files even less. But maybe there's a third way...?
Best regards, Martijn
> Maintain the cluster revision table
> -----------------------------------
>
> Key: JCR-1087
> URL: https://issues.apache.org/jira/browse/JCR-1087
> Project: Jackrabbit
> Issue Type: Improvement
> Components: clustering
> Affects Versions: 1.3
> Environment: A clustered Jackrabbit
> Reporter: Martijn Hendriks
> Priority: Minor
> Attachments: cluster-trace.txt, JCR-1087-v2.patch, JCR-1087.patch
>
>
> The revision table in which cluster nodes write their changes can potentially
> become very large. If all cluster nodes are up to date to a certain revision
> number, then it seems unnecessary to keep the revisions with a lower number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
