Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <20815779.1171548425881.JavaMail.jira@brutus>
Date: Thu, 15 Feb 2007 06:07:05 -0800 (PST)
From: =?utf-8?Q?Claus_K=C3=B6ll_=28JIRA=29?= <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-204) Improve recoverability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-204?page=3Dcom.atlassian.ji=
ra.plugin.system.issuetabpanels:comment-tabpanel#action_12473382 ]=20

Claus K=C3=B6ll 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.=20
But if i search something that normaly matches the node i get this message
WARN  - Exception retrieving Node with UUID: 63baf280-439f-3b38-44c3-d54bfd=
29a636: javax.jcr.ItemNotFoundException: 63baf280-439f-3b38-44c3-d54bfd29a6=
36=20
Is the behaviour at the moment (i'm using 1.2.1) that the index will be cre=
ated 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 ObservationM=
anager are not. Consequently, it may happen that the index is not up-to-dat=
e with the workspace data in case of a crash.
> Consider the following cases:
> 1)
> - changes in a ChangeLog are successfully stored by the persistence manag=
er
> - 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 manag=
er
> - system crashes
> -> the index is missing all changes
> To prevent situations like 1) the index must be fully transactional imple=
menting 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 exampl=
e 2)
> To prevent situations like 2) the observation manager musts keep track of=
 transactions and make sure that committed transactions (the ones that succ=
essfully 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!

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.