Not a problem - registering the resource as a service is a simple idea that sounds good. I even advocated it in my book! I then spent 3 years helping people fix the same persistence problems over and over which definitely changed my mind…
That’s why I (and a bunch of other OSGi Alliance members) have spent the last 3-4 years advocating people do transactions and resources differently. The small amount of boilerplate code is annoying, but it completely eliminates the lifecycle and service linking issues that we used to have with the invisible “joining up” of the old transaction behaviour. The whole thing is much more reliable. Totally worth it :) Tim > On 7 Feb 2019, at 15:42, Alex Soto <alex.s...@envieta.com> wrote: > > Thank you Tim, I am glad I asked. > > Best regards, > Alex soto > > > > >> On Feb 7, 2019, at 9:26 AM, Tim Ward <tim.w...@paremus.com >> <mailto:tim.w...@paremus.com>> 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 <alex.s...@envieta.com >>> <mailto:alex.s...@envieta.com>> 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 <tim.w...@paremus.com >>>> <mailto:tim.w...@paremus.com>> 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 <alex.s...@envieta.com >>>>> <mailto:alex.s...@envieta.com>> 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 <t...@mccarthy.co.nz >>>>>> <mailto:t...@mccarthy.co.nz>> 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> >>>>> >>>> >>> >> >
