jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Köll (JIRA) <j...@apache.org>
Subject [jira] Commented: (JCR-204) Improve recoverability
Date Thu, 15 Feb 2007 14:07:05 GMT

    [ https://issues.apache.org/jira/browse/JCR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473382

Claus Köll commented on JCR-204:

I think my problem is what you are describe here.
I have a J2C ResourceAdapter and if i add a Node to the repository and mark the Transaction
as Rolledback the node is not stored in the
Oracle DB. 
But if i search something that normaly matches the node i get this message
WARN  - Exception retrieving Node with UUID: 63baf280-439f-3b38-44c3-d54bfd29a636: javax.jcr.ItemNotFoundException:
Is the behaviour at the moment (i'm using 1.2.1) that the index will be created before the
persistencemanager commits the transaction ?

> Improve recoverability
> ----------------------
>                 Key: JCR-204
>                 URL: https://issues.apache.org/jira/browse/JCR-204
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core, indexing, observation, transactions
>         Environment: svn revision: 265028
>            Reporter: Marcel Reutegger
>         Assigned To: 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
> 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.

View raw message