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