jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-2503) inconsistent session and persistent state after ReferentialIntegrityException
Date Thu, 25 Feb 2010 14:49:28 GMT

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

View raw message