[
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.
