You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2005/08/31 15:08:05 UTC
[jira] Created: (JCR-204) Improve recoverability
Improve recoverability
----------------------
Key: JCR-204
URL: http://issues.apache.org/jira/browse/JCR-204
Project: Jackrabbit
Type: Improvement
Components: core, observation, query
Environment: svn revision: 265028
Reporter: Marcel Reutegger
Assigned to: Marcel Reutegger
Priority: Minor
Fix For: 1.0
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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-204) Improve recoverability
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-204?page=all ]
Jukka Zitting updated JCR-204:
------------------------------
Fix Version: 1.1
(was: 1.0)
> Improve recoverability
> ----------------------
>
> Key: JCR-204
> URL: http://issues.apache.org/jira/browse/JCR-204
> Project: Jackrabbit
> Type: Improvement
> Components: observation, query, core
> Environment: svn revision: 265028
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
> Fix For: 1.1
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-204) Improve recoverability
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-204?page=comments#action_12329418 ]
Marcel Reutegger commented on JCR-204:
--------------------------------------
The query handler is not fully transactional. If an update operation on the index is interrupted it is rolled back when the index starts up again.
The redo log now includes not just information about the volatile part of the index but covers all operations.
This solves issue 1).
svn revision: 289211
> Improve recoverability
> ----------------------
>
> Key: JCR-204
> URL: http://issues.apache.org/jira/browse/JCR-204
> Project: Jackrabbit
> Type: Improvement
> Components: core, observation, query
> Environment: svn revision: 265028
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
> Fix For: 1.0
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira