Hi Chris, you have understood my case correctly. Thank you for your clarifying explanations!
Although there might be a small risk for the "timing problem", I think subsystems could help. At least a subystem expresses clearly what belongs together and avoids unintentionally stopping of modules that belong to the subsystem. So I think I give it a try. Thank you and all others for your contributions. Best regards, Andreas -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Samstag, 21. März 2015 10:26 An: OSGi Developer Mail List Betreff: Re: [osgi-dev] persistence, lazy loading and service dynamic Hi Andreas, > There are modules representing features of an application. These > modules should be dynamic. And there are modules representing an > architectural layer of an feature. This modules should NOT be dynamic. > They should share the dynamic of the feature module. I'm not 100% sure I understand what you are saying here, but if the second type of module is one whose lifecycle can be interpreted as applying to a whole aggregate of functionality then subsystems could be the way to go. > So I am wondering if this could be achieved with subsystems. So far I > have no experience with subystems and I try to figure out if it is > worth using them for my case. The language of the specification is not very encouraging with respect to the "timing problem". Take this paragraph (from <https://osgi.org/javadoc/r5/enterprise/org/osgi/service/subsystem/Subsystem.html#stop()>): "Implementations should be sensitive to the potential for long running operations and periodically check the current thread for interruption, in which case a SubsystemException with an InterruptedException as the cause should be thrown. If an interruption occurs while waiting, this method should terminate immediately. Once the transition to the STOPPING state has occurred, however, this method must not terminate due to an interruption until the stop process has completed." So the subsystem can spend a long time in the STOPPING state, and the operation to stop it may have already encountered difficulties which it has not yet been able to report. In effect you replace many small areas of uncertainty by one large one - which may be easier to handle, but at the micro level the timing uncertainty is still there. I don't believe this uncertainty *can* be removed by some magic of synchronisation, n-phase commits, or whatever. The most you could hope to achieve would be to prevent an unchecked exception from being thrown by delaying recognition of the underlying problem. If I write SMBusService s = smBusRef.get(); if (s != null) { s.write(addr,val) } else { mumble() } and the wire comes un-soldered somewhere between the get() and the write() then the latter is going to fail. And as this is a rare(*) and unpredictable event an exception is the right way to deal with it. Best regards Chris (*) Not so rare if I did the soldering - but that's why they call me a software engineer. > -----Ursprüngliche Nachricht----- > Von:Peter Kriens <[email protected]> Gesendet:Do 19.03.2015 18:19 > Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic > An:OSGi Developer Mail List <[email protected]>; Very nicely > said. In the real world shit happens and you need to deal with it. The > worst applications are the ones that pretend shit does not happen, > they are the most fragile. Since shit can always happen (like a power > failure) any application that relies on no-shit happening is bound to > fail one day. So you need to recover from NPE in any complex > application, power outages, network failures, etc. Get over it, and handle > them. > > As Chris said, it is part of modularity that you're calling an unknown > party. The authors could throw an NPE as well, a ServiceException is > just one of this unpreventable things. > > That said. The OSGi dynamics are 'slow' dynamics. They are not > intended to be used in the mainline of the application and cycle > hundreds of times per second. I've been programming with this model a > long time and never had the urge to do something special to prevent > this small window. You might see some wrong data on the GUI for a > fraction of a second but good code will handle the subsequent shutdown > event and grey out or remove the culprit. > > Trust me, this is the LEAST of your worries in today's software :-) > > Kind regards, > > Peter Kriens > > > > >> On 19 mrt. 2015, at 15:05, [email protected] wrote: >> >> Hi Andreas, >> >>> So I think with some unlucky timing there allways remains a small >>> risk of failure when calling a service due to service dynamic. >> >> Yes. >> >>> My question is, if it is possible to avoid this small risk? >> >> No. Or to put it another way: when you invoke a service you are >> always (in >> principle) invoking "unknown" code which may not behave the way you >> expect, so you should program defensively. Be prepared for the >> service to fail, and take the time to think what you should do if it >> does - propagate the failure? or try to carry on? >> >> To me this is a part of modularity, independent of dynamics - within >> your service you should not need to perform many checks, but you >> should check the parameters with which you are invoked and if you >> call another service you should treat it as fallible. >> >> Chris >> >> >>> -----Ursprüngliche Nachricht----- Von:David Bosschaert >>> <[email protected]> Gesendet:Mi 18.03.2015 21:45 >>> Betreff:Re: [osgi-dev] persistence, lazy loading and service dynamic >>> An:OSGi Developer Mail List <[email protected]>; Hi Andreas, >>> >>> If I understand your email correctly the following is your concern: >>> >>>> So it may occur, that a call by the DomainsService on a property of >>>> an entity happens when the DAO-Service is not available anymore. >>>> ... >>>> What options do I have to safely load the entities? >>> >>> AFAICS you really have two options: >>> 1. If the service is gone, the call will fail. Maybe you can >>> gracefully deal with the failure. >>> 2. If the dependent service is gone then make sure the depending >>> code does not run. This is really the approach taken by DS. If you >>> declare a mandatory dependency on your DAO service for the >>> DomainService code then if the DAO service disappears the >>> DomainService will also not exist. In DS mandatory dependencies are the >>> default model. >>> >>> Option 2. above is clearly the most elegant scenario. Does this >>> cover your concern or is there something that I missed? >>> >>> Best regards, >>> >>> David >>> >>> >>> On 14 March 2015 at 16:41, Andreas Klotz <[email protected]> >>> wrote: >>>> Hi all, >>>> >>>> >>>> >>>> I have an use case where I want the dynamic of a service to be >>>> bound to another higher level service. Maybe I need Subsystems...? >>>> >>>> >>>> >>>> I think it is a good design of an OSGi-service if it just provides >>>> data in contrast to provide objects on which an operation can be >>>> performed that is using resources of the underlying bundle. >>>> Although the second variant would be possible, I think that >>>> handling service/bundle dynamic becomes very complex or even >>>> unmanageable. >>>> >>>> >>>> >>>> However there is a use case where I can't deliver just data by a >>>> service. I think of lazy loading when dealing with persistence. >>>> >>>> I usually define interfaces for the data access layer. So I get a >>>> Bundle-Setting like this: >>>> >>>> >>>> >>>> - Entity-Bundle (contains Entities) >>>> >>>> - DataAccessAPI-Bundle (contains DAO-Interfaces) >>>> >>>> - DataAccessImpl-Bundle (provides Services implementing >>>> DAO-Interfaces) >>>> >>>> - DomainService_A-Bundle (contains domain Logic for e.g. a GUI, >>>> uses DAO-Services; would be separated in API and impl of course) >>>> >>>> - DomainService_B-Bundle (contains more domain Logic, uses same >>>> DAO-Services as DomainsService_A) >>>> >>>> >>>> >>>> DomainServices A and B are clients of DAO-Services. A DAO-Service >>>> may provide an entity with some lazy loading properties. The >>>> transactions of the data accesses are defined by the >>>> DomainServices. So it may occur, that a call by the DomainsService >>>> on a property of an entity happens when the DAO-Service is not >>>> available anymore. That would lead to an unsuccessful attempt to >>>> load the property lazily (assuming that connections to the database >>>> are managed by the DAO-Bundle and not by a separate e.g. >>>> EntityManager-Service). So the DAO-Service delivered an object that >>>> tries to perform an operation on its delivering service. >>>> >>>> >>>> >>>> What options do I have to safely load the entities? >>>> >>>> - Do not use lazy Loading? I know cases where this would load the >>>> whole DB in to the RAM... >>>> >>>> - Make assumptions about certain properties a client might need and >>>> load them explicitly in the DAO-Layer? This will not work if I have >>>> different clients for one DAO-Service. >>>> >>>> - Is there a possibility to package DomainServices A and B as >>>> different Subsystems with the DAO-Service as a shared capability? >>>> Would this have the effect that the bundle providing the >>>> DAO-Service will only be stoppable, if both DomainServices are >>>> stopped? >>>> >>>> >>>> >>>> To be more general: In our OSGi-projects we use micro-services >>>> intensely to loosely couple not only domain logic (vertical) but >>>> also the architectural layers (horizontal). And I often feel that I >>>> only want dynamic for the vertical bundles/services. >>>> >>>> >>>> >>>> I am very interested in your opinion and how you deal with lazy >>>> loading or equivalent cases. >>>> >>>> >>>> >>>> Thanks and best regards, >>>> >>>> à  à  à  à  à  à  à  à  Andreas >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 _______________________________________________ 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
