I know that Apache Felix iPOJO would not release references of ServiceT to A or B (if A or B are removed) when ServiceT.doStuff() is being called. Service release happen as soon as the executing Thread exits the SeviceT.doStuff() method. As when service unregistration happens, the framework calls service listeners synchronously, this behavior, some kind of freeze the dependency for a (short) time (upon the methods execution is finished).
--G 2013/9/10 Thomas Diesler <[email protected]> > The proposal is targeted for a specific project (fuse-fabric) - remote > services are not involved in the consideration at the moment. The problem > however seems to be general enough that I wanted to present it to this > audience. I'm wondering how other folks deal with the issues of service > dynamicity and configuration change in the duration of a single call to a > complex graph of interconnected services. > > cheers > --thomas > > > On Sep 10, 2013, at 1:35 PM, BJ Hargrave <[email protected]> wrote: > > You still have the issue that services are transient. You cannot "pin" a > set of them for some time duration. A service can represent a remote > service, access to which is subject to failure of the network or remote > withdrawal of the service. > > But I am not totally sure I understood your proposal. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > From: Thomas Diesler <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 2013/09/10 07:01 > Subject: [osgi-dev] Fabric Service Model - Request for feedback > Sent by: [email protected] > ------------------------------ > > > > Hi Folks, > > in Fabric we have a service model whereby services have interdependencies, > are configurable and dynamic by nature - all of which is managed in OSGi > with the help of Declarative Services. To illustrate I use a simple example > > ServiceT { > > @Reference > ServiceA serviceA; > > @Reference > ServiceB serviceB; > > public doStuff() { > // that uses serviceA & serviceB > } > } > > The injection is handled by the DS framework - there are various callbacks > involved. > > Lets assume the system is fully configured and a client makes a call on > ServiceT > > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > > Due to the dynamic nature of OSGi services and their respective > configuration ServiceT must deal with the following possible/likely > situations > > #1 An instance of a referenced service is not available at the point of > access (i.e. serviceA is null) > #2 In the context of a single call the service instance may change (i.e. > call may span multiple instances of serviceA) > #3 In the context of a single call the configuration of a service instance > may change (i.e. serviceA is not immutable, sequential operations on A may > access different configurations) > > In OSGi there is no notion of global lock for service/configurations nor a > notion of lock of a given set of services/configurations - I cannot do > > lock(T, A, B); > try { > ServiceT serviceT = getServiceT(); > serviceT.doStuff(); > } finally { > unlock(T, A, B); > } > > This code is also flawed because it assumes that the caller of doStuff() > is aware of the transitive set of services involved in the call and that > this set will not change. > > As a conclusion we can say that the behaviour of doStuff() is only defined > when we assume stability in service availability and their respective > configuration, which happens to be true most of the time - nevertheless, > there are no guarantees for defined behaviour. > > How about this … > > The functionality of A and B and its respective configuration is decoupled > from OSGi and its dynamicity > > A { > final Map config; > public doStuffInA() { > } > } > > B { > final Map config; > public doStuffInB() { > } > } > > ServiceA and ServiceB are providers of immutable instances of A and B > respectively. There is a notion of CallContext that provides an idempotent > set of instances involved in the call. > > CallContext { > public T get(Class<T> type); > } > > This guarantees that throughout the duration of a call we always access > the same instance, which itself is immutable. CallContext also takes care > of instance availability and may have appropriate timeouts if a given > instance type cannot be provided. It would still be the responsibility of > A/B to decide wether an operation is permissible on stale configuration. > > Changes to the system would be non-trival and before I do any prototyping > I'd like to hear what you think. > > cheers > --thomas > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > Thomas Diesler > JBoss OSGi Lead > JBoss, a division of Red Hat > xxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
