[
https://issues.apache.org/jira/browse/JCR-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Hendriks updated JCR-2129:
----------------------------------
Description:
There are two places where transient state changes are merged with persisted
state: (i) in the SessionISM.stateModified call back method (typically called
by a saving thread after it's changes have been saved) and (ii) in the
SharedISM.Update.begin method. Sometimes the merge strategy fails in the sense
that corrupt data is written to database.
How to reproduce:
The attached test program contains steps to reproduce the issue. The
testInconsistency1 method concurrently adds a node D to a node A and moves
child node B of A to another place. This sometimes results in a situation in
which node A still has a child reference to node B whereas B has another
parent. In this situation, Jackrabbit cannot be started anymore if the search
index is missing:
Jun 8, 2009 2:16:23 PM
org.apache.jackrabbit.core.query.OnWorkspaceInconsistency$1
handleMissingChildNode
SEVERE: Node /A (a7a29e8c-8d13-4fbd-b0ca-4f93f9c0ef42) has missing child 'B'
(80aa13c5-1db6-4f62-b576-5e7f626d90c1)
Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.RepositoryImpl
initStartupWorkspaces
SEVERE: Failed to initialize workspace 'wm9'
The testInconsistency2 method concurrently adds a reference property to a node
B (the threads do exactly the same). This sometimes results in a situation in
which the referenced node can never be removed anymore because there is a
"ghost" reference to it which cannot be removed. (It gives a
ReferentialIntegrityException).
Jun 8, 2009 2:19:51 PM org.apache.jackrabbit.core.state.MLRUItemStateCache cache
WARNING: overwriting cached entry bc28ff87-216d-4ccd-bd73-03e7499ab54e/{}ref to
B
Exception in thread "main" javax.jcr.ReferentialIntegrityException:
9f025634-d3e1-448e-904c-1c285f6b1bf6: the node cannot be removed because it is
still being referenced.
It seems the first problem (the parent-child relation) is caused by an
incorrect merge in the NodeStateMerger class. The second problem might also be
caused by an incorrect or missed merge, but I am not sure whether that's the
real problem.
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 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).
Summary: Prevent data inconsistencies due to incorrect or missed merges
in the ItemStateManagers (was: Prevent data inconsistencies due to missed
merges in the SharedItemStateManager)
> Prevent data inconsistencies due to incorrect or missed merges in the
> ItemStateManagers
> ---------------------------------------------------------------------------------------
>
> 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
>
>
> There are two places where transient state changes are merged with persisted
> state: (i) in the SessionISM.stateModified call back method (typically called
> by a saving thread after it's changes have been saved) and (ii) in the
> SharedISM.Update.begin method. Sometimes the merge strategy fails in the
> sense that corrupt data is written to database.
> How to reproduce:
> The attached test program contains steps to reproduce the issue. The
> testInconsistency1 method concurrently adds a node D to a node A and moves
> child node B of A to another place. This sometimes results in a situation in
> which node A still has a child reference to node B whereas B has another
> parent. In this situation, Jackrabbit cannot be started anymore if the search
> index is missing:
> Jun 8, 2009 2:16:23 PM
> org.apache.jackrabbit.core.query.OnWorkspaceInconsistency$1
> handleMissingChildNode
> SEVERE: Node /A (a7a29e8c-8d13-4fbd-b0ca-4f93f9c0ef42) has missing child 'B'
> (80aa13c5-1db6-4f62-b576-5e7f626d90c1)
> Jun 8, 2009 2:16:23 PM org.apache.jackrabbit.core.RepositoryImpl
> initStartupWorkspaces
> SEVERE: Failed to initialize workspace 'wm9'
> The testInconsistency2 method concurrently adds a reference property to a
> node B (the threads do exactly the same). This sometimes results in a
> situation in which the referenced node can never be removed anymore because
> there is a "ghost" reference to it which cannot be removed. (It gives a
> ReferentialIntegrityException).
> Jun 8, 2009 2:19:51 PM org.apache.jackrabbit.core.state.MLRUItemStateCache
> cache
> WARNING: overwriting cached entry bc28ff87-216d-4ccd-bd73-03e7499ab54e/{}ref
> to B
> Exception in thread "main" javax.jcr.ReferentialIntegrityException:
> 9f025634-d3e1-448e-904c-1c285f6b1bf6: the node cannot be removed because it
> is still being referenced.
> It seems the first problem (the parent-child relation) is caused by an
> incorrect merge in the NodeStateMerger class. The second problem might also
> be caused by an incorrect or missed merge, but I am not sure whether that's
> the real problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
