jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-1078) ChangeLog serialization causes cache inconsistencies
Date Thu, 23 Aug 2007 09:36:31 GMT

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

Dominique Pfister resolved JCR-1078.
------------------------------------

    Resolution: Fixed

Wow, that was quick! When comparing my change to yours, the only difference found was the
revision number on top. Applied the patch and verified that it solves the problem.

Thanks for reporting and submitting a patch, great job!

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


Mime
View raw message