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é <[email protected]>: > 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 <[email protected]>: >> >> 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 >>>> >>>> >>>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
