[
https://issues.apache.org/jira/browse/JCR-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan updated JCR-2503:
-------------------------
Status: Patch Available (was: Open)
This is a failure-atomicity problem in which the ReferentialIntegrityException
leaves the session in an inconsistent state. This issue is closely related to
https://issues.apache.org/jira/browse/JCR-288. In JCR-288 the problem is fixed
for items that were previously persisted. It does not work for items that never
have been persisted.
Rougly the following happens:
- Node P3 is created which was never persisted before and node P1 is removed,
but this is not allowed due to referential integrity.
- Session.save calls ItemImpl.save on the root node.
- Before calling LocalItemStateManager.update() all item states are disposed by
calling SessionItemStateManager.disposeTransientItemState and this invalidates
the state and removes it from the transient store.
- The update call throws a ReferentialIntegrityException
- The exception causes the transient items to be restored by calling
ItemImpl.restoreTransientItems. Restoring is a 3 step process:
- retrieve or recreate the item object
- add the state to the SessionItemStateManager transient store again
- restore the properties in the state object
The problem is that adding the state to the SessionItemStateManager again is
only done for items that where previously persisted (i.e. !isTransient). As a
result node P3 transient state no longer exists when the next save is performed
and P3 is not created, but its parent contains a child node reference to P3.
A possible solution is to:
- Call NodeImpl.restoreTransient and PropertyImpl.restoreTransient also for
transient items.
- Change the NodeImpl.restoreTransient and PropertyImpl.restoreTransient
methods to re-create the state for transient items.
See attached patch which is based on the 1.5 branch.
> inconsistent session and persistent state after ReferentialIntegrityException
> ------------------------------------------------------------------------------
>
> Key: JCR-2503
> URL: https://issues.apache.org/jira/browse/JCR-2503
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 1.5.8, 1.6.2, 2.1.0
> Environment: win7 / jdk 1.6.0_17 / mvn 2.0.10
> Reporter: Bram de Kruijff
> Priority: Critical
> Attachments: CorruptionTest.java, JCR-2503.patch,
> JR-inconsistencies-1.5.txt
>
>
> When a ReferentialIntegrityException occurs in a session it seems that
> subsequent actions on that session may result in a inconsistent session state
> AND even inconsistent persistent state. The latter will even make jackrabbit
> fail to bootstrap an index from that persistent state.
> Typical rootcause:
> Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException:
> ddb9d3ea-59c1-4eb4-a83e-332f646d4f40
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:270)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.createIndex(MultiIndex.java:1082)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.createIndex(MultiIndex.java:1088)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.createInitialIndex(MultiIndex.java:395)
> Bootstrap failure:
> java.io.IOException: Error indexing workspace
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.createInitialIndex(MultiIndex.java:402)
> at
> org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:465)
> at
> org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
> at
> org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:553)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
