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
