aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: JPA blueprint and thread safety
Date Tue, 09 Sep 2014 13:06:53 GMT
Thanks for the update.

Regards
JB

On 09/09/2014 11:22 AM, Guillaume Nodet wrote:
> Fwiw, my fix seems to work great.  There's no more concurrency issues afaik.
>
>
> 2014-09-09 11:10 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>
>> Hi,
>>
>> It looks better to me to "maintain" the same EM in the thread instead of
>> cleaning after each call.
>> For the concurrency issue, I don't see any valid fix for that.
>> Maybe we can imagine a kind of controlled factory service for EM returning
>> a sync EM for the ThreadLocal, but not sure it will fix the issue.
>>
>> Regards
>> JB
>>
>>
>> On 09/04/2014 09:49 AM, Guillaume Nodet wrote:
>>
>>> I pushed a possible fix in https://github.com/gnodet/aries/tree/ARIES-885
>>> (tests don't pass yet, see below).
>>> The idea slightly changes the design.
>>> The injected beans are wrapped with a blueprint interceptor to track
>>> calls.
>>>    The EntityManagerFactory now uses a single instance of JTAEntityManager.
>>>    When not using a transaction, an entity manager is retrieved from a pool
>>> and associated with the current thread.  When the thread is done, the
>>> entity manager is cleared and put back in the pool.
>>> There is a small behavioral change in that the EM is only cleared when the
>>> thread is done with the EM, but not after each call (i.e. you can chain
>>> multiple calls to the EM in a single method without having the EM cleared
>>> in between).
>>> It seems to me actually better.
>>> Fwiw, the main problem I face is concurrency issues in the EM because even
>>> if the shared EM has been wrapped some time ago in a synchronized wrapper,
>>> Query objects returned aren't synchronized and this leads to various
>>> exceptions when load testing with multiple threads.
>>> Anyway, thoughts welcomed !
>>>
>>> 2014-09-03 11:09 GMT+02:00 Guillaume Nodet <gnodet@apache.org>:
>>>
>>>   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 <chris@die-schneider.net
>>>>> :
>>>>
>>>>   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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message