You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2013/08/02 16:51:47 UTC

[jira] [Commented] (FELIX-4190) The framework should not hold any lock while calling ServiceFactory#unget

    [ https://issues.apache.org/jira/browse/FELIX-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727714#comment-13727714 ] 

Richard S. Hall commented on FELIX-4190:
----------------------------------------

Reiterating a comment from email:

Technically, I think this patch is not correct.

We specifically allow for bundles that already hold the service reference to acquire the service object while a service is being unregistered (see comments in ServiceRegistry.unregisterService()). This means that a bundle that already holds the service reference could, technically, acquire the unregistering service just after you call getUsingBundles(), thus we wouldn't be forcing it to unget.

The only way I think we can do what you want is to somehow acquire the registry lock (i.e., this) again and put us into some new state that doesn't allow any more bundles to acquire the unregistering service...or perhaps by adding something to the service registration to put it into a new state where it won't return anything from getService. Then we could release the registry lock and continue with what you have. 
                
> The framework should not hold any lock while calling ServiceFactory#unget
> -------------------------------------------------------------------------
>
>                 Key: FELIX-4190
>                 URL: https://issues.apache.org/jira/browse/FELIX-4190
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>            Reporter: Guillaume Nodet
>            Assignee: Guillaume Nodet
>             Fix For: framework-4.4.0
>
>


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