[
https://issues.apache.org/jira/browse/FELIX-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531149#comment-13531149
]
Guillaume Nodet commented on FELIX-3807:
----------------------------------------
The bundle lock can be acquired before the global lock and the two threads will
be processing and lead to the scenario I described above I think.
The main reason is that if the bundle is stopped, the refresh thread won't even
try to grab the bundle lock, so the thread that has the lock can actually start
the bundle.
That's why the refresh thread need to ensure it grabs the bundle lock, to
actually have what you describe, i.e. have the refresh thread wait for other
threads to finish.
I think it's not the case currently.
Another way may be to always call bundle#stop() irrespective of the bundle
state in the RefreshHelper as it would cause the thread to grab the lock in all
cases.
Though the bundle state retrieved just before stopping might still be wrong
because another thread could still have the lock at this point.
So I think grabbing all the lock first is the safest way.
> Refreshing bundles should first grab all the bundle locks to avoid concurrent
> modifications of those bundles
> ------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3807
> URL: https://issues.apache.org/jira/browse/FELIX-3807
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Reporter: Guillaume Nodet
>
> This will avoid possible problems where bundles states can change between
> stopping the bundle and actually refreshing them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
