jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martijn Hendriks (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-1087) Maintain the cluster revision table
Date Mon, 04 Feb 2008 12:07:07 GMT

     [ 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.


Mime
View raw message