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