aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (Jira)" <j...@apache.org>
Subject [jira] [Commented] (ARIES-2050) Aries JPA 2.7 shouldn't always reuse EM instance from previous coordinations
Date Mon, 09 Aug 2021 04:25:01 GMT

    [ https://issues.apache.org/jira/browse/ARIES-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395788#comment-17395788
] 

ASF subversion and git services commented on ARIES-2050:
--------------------------------------------------------

Commit d017bd7bb735626840a63d6b79db25e28ef82a46 in aries-jpa's branch refs/heads/master from
Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=aries-jpa.git;h=d017bd7 ]

Merge pull request #10 from apache/ARIES-2050

[ARIES-2050] EMSupplier selectes better TX-related coordination to st…

> 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
>          Components: JPA
>    Affects Versions: jpa-2.7.2
>            Reporter: Grzegorz Grzybek
>            Assignee: Grzegorz Grzybek
>            Priority: Major
>             Fix For: jpa-2.7.3
>
>
> 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)

Mime
View raw message