Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <20679320.1187860710722.JavaMail.jira@brutus>
Date: Thu, 23 Aug 2007 02:18:30 -0700 (PDT)
From: "Martijn Hendriks (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-1078) ChangeLog serialization causes cache
 inconsistencies
In-Reply-To: <9748400.1187856041246.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martijn Hendriks updated JCR-1078:
----------------------------------

    Attachment: JCR-1078.patch

Swapping the order of the serialization to:
1) serialize deletedStates
2) serialize modifiedStates
3) serialize addedStates
in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc) should work. Here's a patch for it. I tested it on the scenario from the description and it works there.

> ChangeLog serialization causes cache inconsistencies
> ----------------------------------------------------
>
>                 Key: JCR-1078
>                 URL: https://issues.apache.org/jira/browse/JCR-1078
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering
>    Affects Versions: 1.3
>         Environment: Clustered Jackrabbit 1.3
>            Reporter: Martijn Hendriks
>            Assignee: Dominique Pfister
>         Attachments: JCR-1078.patch
>
>
> The ordering of actions is taken into account when a ChangeLog is built through session manipulations (see, for instance,  ChangeLog.deleted(ItemState state)). When it is serialized in ClusterNode.write(Record record, ChangeLog changeLog, EventStateCollection esc), however, this implicit ordering might be changed. As a consequence,  the deserialization in ClusterNode.consume(Record record) might produce a different ChangeLog with the effect that the local caches get out-of-sync with the persistent state of the repository.
> The issue should be reproducable as follows:
> - Setup a clustered environment with two Jackrabbit instances, say A and B.
> - On instance A add a property "P" with value "x" to some node and save the session.
> - On instance B read property "P" -> it will have value "x".
> - On instance A delete property P and then add it again with value "y" and save the session.
> - On instance B read property "P" -> it will still have value "x" after the cluster sync...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.