[
https://issues.apache.org/jira/browse/JCR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536704
]
Miro Walker commented on JCR-204:
---------------------------------
Afaik the same (similar?) problem exists for version storage operations - it's
possible (and has happened quite frequently) that a workspace is updated, but
the version storage is not, resulting in a reference to a non-existent base
version being left in the workspace, which causes subsequent reads to fail.
> Improve recoverability
> ----------------------
>
> Key: JCR-204
> URL: https://issues.apache.org/jira/browse/JCR-204
> Project: Jackrabbit
> Issue Type: Improvement
> Components: indexing, jackrabbit-core, observation, transactions
> Environment: svn revision: 265028
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
>
> Transactions in Jackrabbit are committed in SharedItemStateManager.store().
> While the call to PersistenceManager.store() is by its definition atomic,
> updates on the index through synchronous notification by the
> ObservationManager are not. Consequently, it may happen that the index is not
> up-to-date with the workspace data in case of a crash.
> Consider the following cases:
> 1)
> - changes in a ChangeLog are successfully stored by the persistence manager
> - the observation manager notifies the query handler about the change
> - the query handler starts to update the index
> - system crashes
> -> the index is missing some changes
> 2)
> - changes in a ChangeLog are successfully stored by the persistence manager
> - system crashes
> -> the index is missing all changes
> To prevent situations like 1) the index must be fully transactional
> implementing ACID properties.
> In case an index update cannot be completed, the index will appear as if the
> update never happened. Which results in a situation described in example 2)
> To prevent situations like 2) the observation manager musts keep track of
> transactions and make sure that committed transactions (the ones that
> successfully stored the changes in the persistence manager) successfully
> notify all listeners. If the system should crash while listeners are notified
> the events must be re-delivered on restart.
> comments and suggestions on alternatives are welcome!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
