[
https://issues.apache.org/jira/browse/ARIES-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated ARIES-2050:
------------------------------------
Description:
I have a scenario consisting of the following call graph:
{noformat}
testService.performTest() [ @Transactional(TxType.REQUIRED) ]
+-- List<Car> cars = carDao.getAllCars()
| +-- return em.createQuery("select c from Car c", Car.class).getResultList()
| (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
|
+-- carDao.createNew(car);
| +-- em.persist(car);
|
+-- newTxTestService.testNewTransaction(transactionManager.getTransaction()) [
@Transactional(TxType.REQUIRES_NEW) ]
+-- List<Car> cars = carDao.getAllCars();
+-- return em.createQuery("select c from Car c",
Car.class).getResultList()
{noformat}
The problem is that inside the method marked with
{{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
underlying {{em}} instance because of:
{code:java}
Coordination getTopCoordination() {
Coordination coordination = coordinator.peek();
while (coordination != null && coordination.getEnclosingCoordination() !=
null) {
coordination = coordination.getEnclosingCoordination();
}
return coordination;
}
{code}
And even if the suspended transaction is not yet committed, the em returns the
persisted (but not yet committed) cars.
The coordination stack consists of (names of coordination objects):
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
* jpa
the top coordination contains {{em}} variable associated with suspended
transaction.
I'm working on a solution that properly assigns _current_ em respecting
tx-demarcated coordinations.
[~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
solution, please share.
For now I think both aries-jpa and aries-blueprint-transaction have to be fixed
(the latter one should put some magical variable to the coordination objects
pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
was:
I have a scenario consisting of the following call graph:
{noformat}
testService.performTest() [ @Transactional(TxType.REQUIRED) ]
+-- List<Car> cars = carDao.getAllCars()
| +-- return em.createQuery("select c from Car c", Car.class).getResultList()
| (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
|
+-- carDao.createNew(car);
| +-- em.persist(car);
|
+-- newTxTestService.testNewTransaction(transactionManager.getTransaction()) [
@Transactional(TxType.REQUIRES_NEW) ]
+-- List<Car> cars = carDao.getAllCars();
+-- return em.createQuery("select c from Car c",
Car.class).getResultList()
{noformat}
The problem is that inside the method marked with
{{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
underlying {{em}} instance because of:
{code:java}
Coordination getTopCoordination() {
Coordination coordination = coordinator.peek();
while (coordination != null && coordination.getEnclosingCoordination() !=
null) {
coordination = coordination.getEnclosingCoordination();
}
return coordination;
}
{code}
The coordination stack consists of (names of coordination objects):
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
*
txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
* jpa
the top coordination contains {{em}} variable associated with suspended
transaction.
I'm working on a solution that properly assigns _current_ em respecting
tx-demarcated coordinations.
[~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
solution, please share.
For now I think both aries-jpa and aries-blueprint-transaction have to be fixed
(the latter one should put some magical variable to the coordination objects
pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
> Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
> ----------------------------------------------------------------------------
>
> Key: ARIES-2050
> URL: https://issues.apache.org/jira/browse/ARIES-2050
> Project: Aries
> Issue Type: Bug
> Affects Versions: jpa-2.7.2
> Reporter: Grzegorz Grzybek
> Assignee: Grzegorz Grzybek
> Priority: Major
>
> I have a scenario consisting of the following call graph:
> {noformat}
> testService.performTest() [ @Transactional(TxType.REQUIRED) ]
> +-- List<Car> cars = carDao.getAllCars()
> | +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> | (em is injected using @PersistenceContext(unitName = "xa-test-unit"))
> |
> +-- carDao.createNew(car);
> | +-- em.persist(car);
> |
> +-- newTxTestService.testNewTransaction(transactionManager.getTransaction())
> [ @Transactional(TxType.REQUIRES_NEW) ]
> +-- List<Car> cars = carDao.getAllCars();
> +-- return em.createQuery("select c from Car c",
> Car.class).getResultList()
> {noformat}
> The problem is that inside the method marked with
> {{@Transactional(TxType.REQUIRES_NEW)}} the {{em}} proxy uses the same
> underlying {{em}} instance because of:
> {code:java}
> Coordination getTopCoordination() {
> Coordination coordination = coordinator.peek();
> while (coordination != null && coordination.getEnclosingCoordination() !=
> null) {
> coordination = coordination.getEnclosingCoordination();
> }
> return coordination;
> }
> {code}
> And even if the suspended transaction is not yet committed, the em returns
> the persisted (but not yet committed) cars.
> The coordination stack consists of (names of coordination objects):
> *
> txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.TestServiceImpl.performTest
> *
> txInterceptor.org.apache.aries.jpa.container.itest.bundle.blueprint.impl.NewTxTestServiceImpl.testNewTransaction
> * jpa
> the top coordination contains {{em}} variable associated with suspended
> transaction.
> I'm working on a solution that properly assigns _current_ em respecting
> tx-demarcated coordinations.
> [~cschneider], [~gnodet], [~jbonofre] if you have an idea about the best
> solution, please share.
> For now I think both aries-jpa and aries-blueprint-transaction have to be
> fixed (the latter one should put some magical variable to the coordination
> objects pushed inside {{org.apache.aries.transaction.TxInterceptorImpl}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
