[
https://issues.jboss.org/browse/AS7-6586?page=com.atlassian.jira.plugin.s...
]
Scott Marlow commented on AS7-6586:
-----------------------------------
in our afterCompletion code, I am thinking of two changes.
1. add a try/catch exception {log + ignore the exception}
2. if we are in a background (reaper) thread and persistence unit definition
"forceClose after tx end" property is false, than defer the closing of the
underlying entitymanager until the gc processes it. The JCA afterCompletion sync should
return the managed database connection to the pool.
I'm not sure how we would check if we are in the reaper thread yet.
JPA afterCompletion sync may be called from non-application thread,
resolve concurrency concern
-----------------------------------------------------------------------------------------------
Key: AS7-6586
URL:
https://issues.jboss.org/browse/AS7-6586
Project: Application Server 7
Issue Type: Feature Request
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP)
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 8.0.0.Alpha1
For transaction scoped entity managers, the closing the of entity manager is deferred
until after the transaction completes.
It is possible that the transaction manager/service may call the Transaction sync from a
non-application thread (tx timeout reaper thread or normal completion in remote propagated
tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere
with normal application usage of the entity manager.
I think that there are two main cases to be concerned with that involve the
afterCompletion sync being invoked in a non-application thread:
# TX reaper or other background thread calls afterCompletion while application thread is
in (transaction scope) entityManager invocation.
# TX reaper or other background thread calls afterCompletion while application thread is
not in (transaction scope) entityManager invocation.
Extended persistence contexts do not get closed when the JTA transaction that they are
joined to are closed (in case anyone is curious).
If we are in #1 above, could we delegate the closing of the EntityManager to the in
progress EntityManager invocation (to avoid closing the thread unsafe invocation)? Or
prevent the background thread from closing the EntityManager until the current
EntityManager invocation completes. Or push the requirement up to the top-level EE
container (e.g. managed bean, EJB3, web, ...).
The related classes are org.jboss.as.jpa.container.TransactionScopedEntityManager (or
AbstractEntityManager) + org.jboss.as.jpa.transaction.TransactionUtil classes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira