Re: [jboss-as7-dev] JTA Synchronization.afterCompletion callback can occur in a background thread but JPA EntityManager must be accessed in single-threaded manner...
On 02/22/2013 04:17 PM, Jason Greene wrote:
On Feb 22, 2013, at 3:13 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
>
> I'm closing the entity manager because its a JPA spec (7.9.1) requirement for the
container to close it:
>
> "After the JTA transaction has completed (either by transaction commit or
rollback), the container closes the entity manager calling EntityManager.close.
> "
We don't have to interpret it literally. When the transaction rolls back (either via
exception or getStatus) take the exact same action that EntityManager.close would take.
The JPA container managed code might not know that the transaction has
completed (in the application thread), as the afterCompletion occurs in
the background thread.
>
> If I don't close it, the GC might be able to clean it up for us but that depends
on whether there are any strong references to it. The transaction will get GCd, so the
transaction reference to the EntityManager will disappear. This has potential to create a
memory leak.
No need for GC. We *know* the outcome of the transaction, and we control the
implementation of the entity manager, therefore we can close it in the application thread.
After the background thread commits or rolls back the transaction, the
application thread may not make any further EntityManager calls, so
can't depend on the EntityManager getting control again.
If we can't depend on returning to the top level container (I agree with
what you said about that), how about a component level interceptor that
processes an afterCompletion queue after each invocation?
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat