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