[jira] [Resolved] (SLING-3406) Stale item exception when concurrent topology change events

["Stefan Egli (JIRA)" <ji...@apache.org>]

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

Stefan Egli resolved SLING-3406.
--------------------------------

       Resolution: Fixed
    Fix Version/s: Discovery Impl 1.0.4

chosen the refresh suggestion, as that's the least intrusive. refactoring that whole area would probably be better, but at this stage (1.0.x) I'd prefer small-ish steps.

> Stale item exception when concurrent topology change events
> -----------------------------------------------------------
>
>                 Key: SLING-3406
>                 URL: https://issues.apache.org/jira/browse/SLING-3406
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.0.2
>            Reporter: Jörg Hoh
>            Assignee: Stefan Egli
>             Fix For: Discovery Impl 1.0.4
>
>         Attachments: SLING-3406-stacktrace.txt
>
>
> In the VotingHandler there is the possibility of a race condition, which results in a StaleItemException of the repository.
> the synchronized method analyzeVotings is called with a resourceResolver as parameter; this resourceResolver is created in the non-sychronized method handleEvent.
> When 2 events occur within a short time, the second resourceResolver can get created while the commit of the first one has not yet been processed. Then the second resourceResolver cannot commit its change.
> A solution would be to do the equivalent of "session.refresh()" inside analyzeVotings first, so the repository session is synced. THe other option would be to create the session inside the anaylzeVotings method, so there won't be 2 open resourceResolvers/sessions at any time. Both approaches would prevent the exception.



--
This message was sent by Atlassian JIRA
(v6.2#6252)