Emmanuel, here is a spec reference that illustrates this problem:
JPA spec shows the following example in section 5.7.1.1 - an EJB Session Bean method running within CMT:
Code:
public LineItem createLineItem(Order order, Product product, int quantity) {
EntityManager em = emf.createEntityManager();
LineItem li = new LineItem(order, product, quantity);
order.getLineItems().add(li);
em.persist(li);
em.close();
return li; // remains managed until JTA transaction ends
}
(Note that this is for an application-managed entity manager.)
From my understanding, and from this SPEC example, the EntityManager can be closed prior to transaction commit with the entities remaining managed until JTA transaction completion. Hence, the close call is supposed to be logical, with the underlying resource kept open and closed after transaction completion.
The concrete scenario I am seeing:
* my code uses an EM and then closes it (as in the example above)
* the transaction is then committed, which triggers hibernate validator
* hibernate validator throws an exception (as expected)
* AEMI.throwPersistenceException catches the validator exception and invokes markForRollback
* AEMI.markForRollback, as part of its normal processing, invokes getSession
* getSession fails hard because the session is closed
The comment on the close() method in the spec (p46) indicates that the EM should be able to obtain the transaction after close (which is what is logically needed to mark-as-rollback).
So, it seems that even though the EM is closed this flow should work. No? Are there some limitations with application managed EMs with hibernate? Should I file a jira issue with a test?
Any help would be appreciated.
problem I am seeing is that in AbstractEntityManagerImpl.markAsRollback
Login
FAQ
Search
