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-2129) Prevent data inconsistencies due to missed merges in the SharedItemStateManager
Date Sat, 06 Jun 2009 19:06:07 GMT

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


Mime
View raw message