felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Hargrave <hargr...@us.ibm.com>
Subject Re: Contribution of the dependency manager to Feli
Date Mon, 30 Jan 2006 16:13:42 GMT
Marcel Offermans <marcel.offermans@luminis.nl> wrote on 2006-01-28 
06:12:21 AM:

> John E. Conlon wrote:
> >If only one field is specified and if there are multiple services; and
> >the services are dynamically coming and going how will the service
> >referenced in the one field react? 
> > 
> >
> Let's use an example scenario here. Say we have an optional dependency 
> with LogService (quite common) and that at first, there is no log 
> service available. The field will then be initialized with a "null 
> object" so you can safely invoke methods on this log service (but these 
> methods will do nothing).
> Now a log service is registered. At this moment, the instance field will 

> be changed (using reflection). So from this point on, all methods you 
> invoke on log service will actually invoke the freshly added log 
> Now another log service is registered with a higher ranking. Again, the 
> instance field will be modified, rerouting all new calls to the higher 
> ranked log service.
> Now if that higher ranked log service is removed again, the instance 
> will revert to the other, still registered log service. If that one is 
> removed too, you will get a null object again.

Interesting. With the possible asynchronous changes to the field being 
made by the dependency manager, the field MUST be declared volatile or all 
access to it must be protected by a suitable synchronization for proper 
java memory model semantics. Otherwise strange and hard to debug problems 
may arise since different threads can end up using different values for 
the field.

How do you deal with this? While for the log example here, no serious 
problems will arise if the wrong log is used. But if the field references 
some other service, serious bugs could occur.

> For the example of a log service, this instance changing all the time 
> will be just fine. Some log messages will be ignored, or written to the 
> log service, depending on what's available at that time. The log service 

> itself has no state or anything so bundles using it won't care as much 
> about the implementation changing. In these cases, just using the 
> instance field.
> If you do care about changes, you can still use the instance field, but 
> you should at least use the callback hooks too so you are notified and 
> can act on changes to this field (of course, it might be a little more 
> complicated then that, because you will also be notified when a lower 
> ranked service is added and that will not change our instance field).
> So really the bottom line is:
>  - Use the instance field if you want to use the highest ranked service 
> and you don't really care about changing services.
>  - Use callback hooks if you do care about changes, in which case you 
> can decide what to do yourself.
> >(Thanks Marcel - your article is very well written.)
> > 
> >
> Thanks!
> Greetings, Marcel

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
Office: +1 407 849 9117 Mobile: +1 386 848 3788

View raw message