[
https://issues.apache.org/jira/browse/JCR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536503
]
Martijn Hendriks commented on JCR-204:
--------------------------------------
The same problem applies to the cluster revision table as it is updated in a
separate transaction after the search index update. This is problematic as the
crash of one clusternode may corrupt the search indices of all other
clusternodes.
I get the feeling that the persistence managers should not only apply the
changes of a ChangeLog to the persistent content, but should also store the
ChangeLog itself in the same transaction. This stored ChangeLog can then be
used for recovery operations on the search index. (In order to solve the
above-mentioned problem that the SearchIndex is one step behind you only need
the last ChangeLog). I think that the clustering subsystem can be adapted for
this purpose. I.e., move the UpdateEventChannel logic currently in the
ClusterNode class to the peristence managers. Any thoughts on this?
> 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.
