Re: Best practice for context-specific service instances?
Why not exposing your service with the interface, but instead of exposing directly an instance, use a per-thread pooling mechanism ? 2016-10-20 13:10 GMT+02:00 cniehues <christian.nieh...@its-telco.de>: > 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. > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: Best practice for context-specific service instances?
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 <christian.nieh...@its-telco.de> 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.
Re: Best practice for context-specific service instances?
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.
Re: Best practice for context-specific service instances?
Hi Christian, What is it that you’re trying to achieve? > is it possible to have multiple equal instances of a service or is this > breaking the principle rules of OSGI? Yes, you can have multiple service registrations for the same object instance, but this doesn’t make a whole lot of sense. You still only have the one object, so the multiple registrations just make the service registry look more confusing. If what you want is to have the ability to create multiple independent instances (i.e. ones that can have local state) then you can achieve this using a prototype scoped service and the ServiceObjects type from OSGi R6. You will be responsible for garbage collecting this type, although it should be pretty easy to create a Scoped Resource for managing the Scoped Object. > I also see the need of parallel processing of messages. How do you do this > with a single service instance without starting multiple threads? I’m a little confused by this question. There isn’t a way to do parallel processing without multiple threads involved. You may have request-level parallelism (e.g. the threads are at the level of the Servlet Container) or task level parallelism (you break the task into small parallel pieces that run on different threads) but there are always multiple threads involved. The OSGi Async Service may be able to help you with the latter model, but this still involves having multiple threads. Regards, Tim > On 20 Oct 2016, at 07:06, cniehues <christian.nieh...@its-telco.de> wrote: > > I am still asking me the question: is it possible to have multiple equal > instances of a service or is this breaking the principle rules of OSGI? > Because beside my wish of context specific instances I also see the need of > parallel processing of messages. How do you do this with a single service > instance without starting multiple threads? > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048455.html > Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Best practice for context-specific service instances?
I am still asking me the question: is it possible to have multiple equal instances of a service or is this breaking the principle rules of OSGI? Because beside my wish of context specific instances I also see the need of parallel processing of messages. How do you do this with a single service instance without starting multiple threads? -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048455.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Best practice for context-specific service instances?
Thanks for the help, i will have a closer look to the tx-control -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048430.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Best practice for context-specific service instances?
Again - I would suggest that what you want is provided by the Transaction Control specification - you can begin a scope and then all work done within that scope remains isolated until the scope finishes. It’s trivial to provide a resource provider for a service, which gives you the scoping that you want for that service. Resource providers already exist for JDBC and JPA, which may give you what you want out of the box already. > On 19 Oct 2016, at 09:41, cniehues <christian.nieh...@its-telco.de> wrote: > > I want to ensure that changes in the database/persistence-unit that have not > been committed are only visible to the instances handling the same request. > But the EntityManager is only an example, I am looking for something like a > context singleton scope for service instances. Think about a service that > will be used multiple times that has a longer running initiation process > depending on the request content. > Is there maybe a factory I can extend? > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html > Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Best practice for context-specific service instances?
I dont think this is possible with OSGi services in general. As far as I know a service can have a singleton or prototype scope. Prototype means the service is instantiated once per requesting bundle. In tx control as well as in Aries JPA the entitymanager instance is bound to a thread. So if you use the same thread you get the same EntityManager through one call. This might suit what you need but it is only working for the EntityManager. Christian On 19.10.2016 10:41, cniehues wrote: I want to ensure that changes in the database/persistence-unit that have not been committed are only visible to the instances handling the same request. But the EntityManager is only an example, I am looking for something like a context singleton scope for service instances. Think about a service that will be used multiple times that has a longer running initiation process depending on the request content. Is there maybe a factory I can extend? -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Best practice for context-specific service instances?
I want to ensure that changes in the database/persistence-unit that have not been committed are only visible to the instances handling the same request. But the EntityManager is only an example, I am looking for something like a context singleton scope for service instances. Think about a service that will be used multiple times that has a longer running initiation process depending on the request content. Is there maybe a factory I can extend? -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410p4048427.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Best practice for context-specific service instances?
I am not sure I understood how you want the EntityManager instances relate to the request. Could you explain with an example? Christian On 18.10.2016 10:16, cniehues wrote: Is there a way to get context specific service instances in karaf? For example if I process SOAP-Messages concurrently I want to ensure that the underlying DAO services will use the same EntityManager for each specific request. -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: Best practice for context-specific service instances?
It sounds like you should look at the Transaction Control specification in the OSGi Release 7 specification draft (https://osgi.org/download/osgi.cmpn-7.0.0-earlydraft1.pdf <https://osgi.org/download/osgi.cmpn-7.0.0-earlydraft1.pdf>) There’s already a prototype implementation in Apache Aries which supports Local transactions, XA transactions, JDBC and JPA. (http://aries.apache.org/modules/transactioncontrol.html <http://aries.apache.org/modules/transactioncontrol.html>). It sounds as though it will do exactly what you want. Regards, Tim > On 18 Oct 2016, at 09:16, cniehues <christian.nieh...@its-telco.de> wrote: > > Is there a way to get context specific service instances in karaf? For > example if I process SOAP-Messages concurrently I want to ensure that the > underlying DAO services will use the same EntityManager for each specific > request. > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410.html > Sent from the Karaf - User mailing list archive at Nabble.com.
Best practice for context-specific service instances?
Is there a way to get context specific service instances in karaf? For example if I process SOAP-Messages concurrently I want to ensure that the underlying DAO services will use the same EntityManager for each specific request. -- View this message in context: http://karaf.922171.n3.nabble.com/Best-practice-for-context-specific-service-instances-tp4048410.html Sent from the Karaf - User mailing list archive at Nabble.com.
