[
https://issues.jboss.org/browse/AS7-6586?page=com.atlassian.jira.plugin.s...
]
Scott Marlow updated AS7-6586:
------------------------------
Description:
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.
was:
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).
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