Hi, It sounds as though the OSGi Async service would be helpful for you in doing asynchronous work (i.e. thread offloading) into services. Where those services need access to objects with state they can make use of prototype scoped services to do so.
It could also be interesting to use Transaction control to make the prototype scope services “scoped” to a piece of work without explicit lifecycle management code. This would also avoid the need to pass the stateful service object alongside the the rest of the call. Given the new structure of the Aries Transaction Control project it should be pretty easy to add a resource provider which supports prototype scoped services. Tim > On 20 Oct 2016, at 12:10, cniehues <[email protected]> wrote: > > Hi Tim, > > You are right, maybe the thread node was a little bit too confusing. > > Here is a concrete example: > I am receiving SOAP messages with camel cxf endpoints that will result in > some complex operations lasting some time. To reach a quick processing of > the messages I use camel:seda with concurrent consumers. So if all > underlying operations will use singleton services I think I will loose the > advantage of the parallel processing and will get trouble with keeping > things thread-safe. Also I want to have some stateful services holding > intermediate data or working like a cache for each specific SOAP request. > This is the reason why I want to have different service instances for each > SOAP request but also want the same instance if I use the service again in a > later step in another bundle. > > I hope my requirements are a little more clear now. Currently we are using > JBoss AS6 and achieve this requirements with our own ComponentFactory and > now we want to switch the application to the OSGI world. > > Regards > > Christian > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048470.html > Sent from the Karaf - User mailing list archive at Nabble.com.
