[jira] Updated: (JCR-2449) Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)

["Thomas Mueller (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Mueller updated JCR-2449:
--------------------------------

    Attachment: JCR-2449.patch

This patch solves the performance problem introduced by JCR-2138. The unit tests of jackrabbit-core still work for me after applying the patch.

I don't really understand what the problem was before JCR-2138. 

Was it a clustering issue? If yes, then the check introduced doesn't really work. Reason: 1) first it checks if references were added, and if yes, then 2) the references are removed. However if the second cluster node adds the references between 1) and 2) then it will still not work.

If it was not a clustering problem, then why do you check if the node already exists in the 'addedStates' list? Those by definition don't exist (they are added, that's the reason to call it 'addedStates'). As far as I understand, saving is synchronized. Is it only a problem if a non-default ISMLocking is used?


> Slow performance due to JCR-2138 (Prevent persistence of faulty back-references)
> --------------------------------------------------------------------------------
>
>                 Key: JCR-2449
>                 URL: https://issues.apache.org/jira/browse/JCR-2449
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.5.7, 2.0-beta4
>            Reporter: Thomas Mueller
>         Attachments: JCR-2449.patch
>
>
> In revision 782898, the following code was introduced:
> updateReferences() {
>     for (Iterator i = local.addedStates(); i.hasNext();) {
>         ...
>         if (hasItemState(state.getId())) {
>             ...
>         }
>     }
> }
> This will try to fetch inexistent nodes from the persistence manager.
> Depending on the persistence manager implementation, this is very slow.
> I hope there is a way to avoid this call, or if not, speed it up.

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