Thank you Tim, I am glad I asked. Best regards, Alex soto
> On Feb 7, 2019, at 9:26 AM, Tim Ward <[email protected]> wrote: > > Hi, > > The model is the way it is quite deliberately, and there are several usage > issues with doing what you’re suggesting: > > It is unclear whether the EntityManager service is a scoped resource (and > therefore managed) or not to external users > It is unclear which Transaction Control service implementation the scoped > resource is attached to (the getResource(txControl) call creates an important > link). If you use the wrong Transaction Control implementation (there may be > several) then it won’t work properly. > It becomes harder to debug what’s going on because there are more “non > obvious" links between services > > These issues (and a few others) are problems that people hit repeatedly when > trying to use DataSources and Transactions together in OSGi. I have seen > *many* applications where people did not realise that their carefully set up > transactions didn’t roll back because they were using the wrong datasource > service, or it had been bound to a different transaction manager than the one > they were using to start the transaction. > > Therefore, while it is possible to do what you’re suggesting I would > *strongly* encourage you not to do it. We’ve been there before and it sucked > so hard that it resulted in us creating a whole new specification to fix the > problems (namely the Transaction Control specification!). > > If you’re able to use Declarative Services 1.4 (you possibly aren’t) then you > could simplify your example a little using constructor injection: > > private final EntityManager em; > private final TransactionControl txControl; > > @Activate > public MyServiceImpl(@Reference(target = > "(osgi.unit.name=myPersistenUnit)”) > JPAEntityManagerProvider provider, @Reference > TransactionControl txControl) { > > this.txControl = txControl; > em = provider.getResource(txControl); > > } > > Best Regards, > > Tim > >> On 7 Feb 2019, at 15:02, Alex Soto <[email protected] >> <mailto:[email protected]>> wrote: >> >> I am wondering if it makes sense to create the scoped EntityManager as a >> singleton service to be then @Referenced by the various repositories. I >> have various repository classes that need the EntityManager, all would need >> to have some code like this: >> >> @Reference(target = "(osgi.unit.name=myPersistenUnit)") >> private JPAEntityManagerProvider provider; >> >> private EntityManager em; >> >> @Activate >> void init() { >> em = provider.getResource(txControl); >> } >> >> >> So each Repository component creates its own Scoped EntityManager. Does it >> make sense to have one component in the application that creates a single EM >> and have the various repositories use that one from the Service Registry? >> >> Best regards, >> Alex soto >> >> >> >> >>> On Feb 6, 2019, at 4:40 PM, Tim Ward <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> The relevant specification for learning about scoped resources (which is >>> what the ResourceProvider gives you) is the Transaction Control >>> Specification. In this case your question is covered by Section 147.2.5 >>> Multi Threading >>> <https://osgi.org/specification/osgi.cmpn/7.0.0/service.transaction.control.html#d0e127038>. >>> >>> >>> Scoped resources are always thread safe and designed to be singleton >>> objects used across multiple scopes. The underlying scoped resource >>> implementation then delegates to a real resource instance that is bound to >>> the current scope. The result is that the real resource never sees >>> multi-threaded access (a scope is bound to a single thread) and that you >>> never need to worry about creating/closing the resource because the “real >>> resource” is automatically created (or retrieved from a pool) on first use >>> within a scope and then closed (or returned to the pool) when the scope >>> finishes. >>> >>> Best Regards, >>> >>> Tim >>> >>>> On 6 Feb 2019, at 22:14, Alex Soto <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Actually, I took a stab at this again since I had some spare time now. I >>>> am almost done. It looks promising. >>>> >>>> The only question I have is about the entity manager. In the examples, I >>>> see an entity manager is obtained in the activate method, and used for the >>>> rest of the life of the component: >>>> >>>> private EntityManager em; >>>> >>>> @Activate >>>> void init() { >>>> em = provider.getResource(txControl); >>>> } >>>> >>>> >>>> Is this safe in a multi threaded environment? I expect the component to be >>>> called concurrently. >>>> Section 127.3.3 of OSGi Companion states that "An Entity Manager is >>>> intended to be used by a single session, it is not thread safe.” So I am >>>> confused since all examples seem to be ignoring this. >>>> >>>> >>>> Best regards, >>>> Alex soto >>>> >>>> >>>> >>>> >>>>> On Feb 6, 2019, at 3:16 PM, Tim Jones <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi Alex, >>>>> >>>>> yes it is possible to use tx-control with Karaf, we have been using it on >>>>> v4.0.5 in our production system for about 18 months with no issues. One of >>>>> the main reasons we use tx-control is that is it 'backed' by a standard. >>>>> Rightly or wrongly we also didn't have confidence in Aries JPA Template at >>>>> the time we were considering transaction managment solutions to manage our >>>>> transactions in a production environment (perhaps this was misguided) but >>>>> we >>>>> were concerned that there were few integrated tests for that project where >>>>> as there are over 2000 lines of test code for tx-control which demonstrate >>>>> sucess and failure cases for JPA, JDBC, non-XA, XA, last gambit wins, >>>>> commit, rollback depending upon exception type and much more. >>>>> >>>>> I think the enRoute project has some examples >>>>> https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html >>>>> <https://enroute.osgi.org/examples/023-examples-microservice-jdbc.html> >>>>> and >>>>> the tx-control test code is worth looking at. >>>>> >>>>> Tim >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html >>>>> <http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html> >>>> >>> >> >
