[
https://issues.apache.org/jira/browse/TOMEE-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044365#comment-16044365
]
Svetlin Zarev edited comment on TOMEE-2057 at 6/9/17 12:27 PM:
---------------------------------------------------------------
I've moved eclipselink's JTASynchronizationListener with the debugger after
openejb's SessionSynchronizationCoordinator for the duration of the request and
this seems to have fixed my issue.
But I'm not sure how can I really fix it, because
SessionSynchronizationCoordinator is being registered in the interposed sync
list, while JTASynchronizationListener is being registered in the "regular"
sync list. The issue is that the interposed list is always executed after the
regular list. In other words @BeforeCompletion is executed always after
eclipselink commits its unit of work.
---
I've modified the JtaTransactionPolicy to register the
SessionSynchronizationCoordinator on the regular sync list instead of the
interposed, thus it will be executed before the JTASynchronizationListener .
[~romain.manni-bucau] What do you think ?
was (Author: svetlinzarev):
I've moved eclipselink's JTASynchronizationListener with the debugger after
openejb's SessionSynchronizationCoordinator for the duration of the request and
this seems to have fixed my issue.
But I'm not sure how can I really fix it, because
SessionSynchronizationCoordinator is being registered in the interposed sync
list, while JTASynchronizationListener is being registered in the "regular"
sync list. The issue is that the interposed list is always executed after the
regular list. In other words @BeforeCompletion is executed always after
eclipselink commits its unit of work.
---
I've modified the JtaTransactionPolicy to register the
SessionSynchronizationCoordinator on the regular sync list instead of the
interposed, thus it will be executed before the JTASynchronizationListener .
What do you think ?
> @BeforeCompletion callback issue
> ---------------------------------
>
> Key: TOMEE-2057
> URL: https://issues.apache.org/jira/browse/TOMEE-2057
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Reporter: Svetlin Zarev
> Attachments: sample-v2.zip, sample.zip
>
>
> I have a @Stateful bean which has @AfterBegin & @BeforeCompletion callbacks
> defined. It tries to persist a JPA entity in each one of them:
> {code}
> @Stateful
> public class SessionBean implements Serializable {
> public static final int ID_AFTER_BEGIN = 1234;
> public static final int ID_BEFORE_COMPLETION = 5678;
> public static final int ID_TX_ENTITY = 9999;
> @PersistenceContext
> EntityManager em;
> @AfterBegin
> public void afterBegin() {
> final TestEntity entity = new TestEntity(ID_AFTER_BEGIN, "On
> AFTER_BEGIN");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_AFTER_BEGIN)){
> throw new IllegalStateException("Entity not persisted in
> AFTER_BEGIN");
> }
> }
> @BeforeCompletion
> public void beforeCompletion() {
> final TestEntity entity = new TestEntity(ID_BEFORE_COMPLETION, "On
> BEFORE_COMPLETION");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_BEFORE_COMPLETION)){
> throw new IllegalStateException("Entity not persisted in
> BEFORE_COMPLETION");
> }
> }
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public void txRequired() {
> final TestEntity entity = new TestEntity(ID_TX_ENTITY, "On
> TX_REQUIRED");
> em.persist(entity);
> if(null == em.find(TestEntity.class, ID_TX_ENTITY)){
> throw new IllegalStateException("Entity not persisted in
> TX_REQUIRED");
> }
> }
> }
> {code}
> During the transaction everything seems fine, but after the transaction
> EntityManger.find() returns null for the bean persisted during
> @BeforeCompletion
> I've attached sample app that reproduces the issue.
> *Expected result:*
> The output does not contain any failed tests.
> *Actual result:*
> {code}
> TESTING TX_REQUIRED WITHOUT EXISTING TRANSACTION
> [TEST FAILED] Expecting entity for BEFORE_COMPLETION instead of: null
> {code}
> PS: I observe a similar issue for @AfterBegin in another case, but I'm not
> able to extract a reproducible test case from it. But I thinkthe two issues
> are linked
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
