I agree with you, it should be easy to use and similar than in JEE.
Currently, a single instance of EntityManager is used, but I think a
possible solution would be to have the JTAEntityManager internally do a
per-thread association, so using a ThreadLocal<EntityManager> for
the detachedManager instead of a single instance.

https://github.com/apache/aries/blob/trunk/jpa/jpa-container-context/src/main/java/org/apache/aries/jpa/container/context/transaction/impl/JTAEntityManager.java#L72




2014-09-03 10:24 GMT+02:00 Christian Schneider <[email protected]>:

> From the user perspective I would like to use the EntityManager like in
> JEE. So without any additional precautions.
>
> Of course this is a lot more difficult as in JEE each ejb thread gets its
> own EntityManager instance. I would expect the aries jpa proxy around the
> EntityManager to make sure the EntityManagers are spearated by threads and
> are thread safe this way. Is this assumption correct?
>
> Christian
>
>
> Am 02.09.2014 09:55, schrieb Guillaume Nodet:
>
>  I was wondering if anyone could cast some lights on thread safety of the
>> EntityManager injected with the <jpa:context /> blueprint element.
>> Some time ago, I raised ARIES-885 and wrapped the inner detachedManager
>> into a synchronized wrapper, but there are still thread safety problems.
>> My main question, is how is the injected EntityManager supposed to be used
>> ? Is is supposed to be thread safe or is the user supposed to synchronize
>> access to it ? I also see that each call is followed by a call to clear on
>> the shared EM, so I'm not quite sure what the effect is supposed to be.
>>
>> Any thoughts welcomed !
>>
>> Cheers,
>> Guillaume Nodet
>>
>>
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Reply via email to