[
https://issues.apache.org/jira/browse/JCR-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Hendriks updated JCR-2129:
----------------------------------
Description:
The SharedItemStateManager.Update class's begin method tests whether states in
the given local ChangeLog are stale. If so, it tries to merge the changes to
the new persisted state. It does this by comparing the modCount of state
instances for non-transient states. There is a race between threads that call
save such that sometimes this test fails and states are not merged when they
should be. As a result, the data in the repository can become corrupt and, for
instance, it becomes impossible to start Jackrabbit or remove certain nodes.
Analysis: persisted state information, including modCount, is pushed down from
another thread while a local ChangeLog is being constructed. The increased
modCount thus appears in the local ChangeLog and the SharedISM falsely assumes
that the state in the local ChangeLog needs no merging (isStale test).
Reproduction:
The attached test program contains steps to reproduce the issue (see comments
of the testInconsistency1 and testInconsistency2 methods).
was:
The SharedItemStateManager.Update class's begin method tests whether states in
the given local ChangeLog are stale. If so, it tries to merge the changes to
the new persisted state. It does this by comparing the modCount of state
instances for non-transient states. There is a race between two threads that
call save such that sometimes this test fails and states are not merged when
they should be. As a result, the data in the repository can become corrupt and,
for instance, it becomes impossible to start Jackrabbit or remove certain nodes.
Analysis: persisted state information, including modCount, is pushed down from
another thread while a local ChangeLog is being constructed. The increased
modCount thus appears in the local ChangeLog and the SharedISM falsely assumes
that the state in the local ChangeLog needs no merging (isStale test).
Reproduction:
The attached test program contains steps to reproduce the issue (see comments
of the testInconsistency1 and testInconsistency2 methods).
> Prevent data inconsistencies due to missed merges in the
> SharedItemStateManager
> -------------------------------------------------------------------------------
>
> Key: JCR-2129
> URL: https://issues.apache.org/jira/browse/JCR-2129
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.5, 2.0.0
> Reporter: Martijn Hendriks
> Priority: Critical
> Attachments: InconsistencyTest.java, repository.xml
>
>
> The SharedItemStateManager.Update class's begin method tests whether states
> in the given local ChangeLog are stale. If so, it tries to merge the changes
> to the new persisted state. It does this by comparing the modCount of state
> instances for non-transient states. There is a race between threads that call
> save such that sometimes this test fails and states are not merged when they
> should be. As a result, the data in the repository can become corrupt and,
> for instance, it becomes impossible to start Jackrabbit or remove certain
> nodes.
> Analysis: persisted state information, including modCount, is pushed down
> from another thread while a local ChangeLog is being constructed. The
> increased modCount thus appears in the local ChangeLog and the SharedISM
> falsely assumes that the state in the local ChangeLog needs no merging
> (isStale test).
> Reproduction:
> The attached test program contains steps to reproduce the issue (see comments
> of the testInconsistency1 and testInconsistency2 methods).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
