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> 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>
>>>
>>
>
