Hi,
we're facing issues with nested JPA.withTransaction calls which result in well known RuntimeException("No EntityManager bound to this thread...").
Here is simplified use-case:
@Transactional
public static Result index() {
JPA.em().isOpen(); // true
// 2nd call to JPA.withTransaction binds new EntityManager to current thread (erasing previously bound EntityManager)
JPA.withTransaction(() -> {
JPA.em().isOpen(); // true
});
// after JPA.withTransaction call there is no EntityManager bound anymore
JPA.em().isOpen(); // RuntimeException: No EntityManager bound to this thread.
return ok();
}
The obvious solution is to keep current EntityManager while new EntityManager is being bound and then rebind it when new EM is no longer used (i.e. at the end of JPA.withTransaction);
see pull request.
Are there any potential or known issues with this solution? Otherwise, what is proper way to make nested JPA.withTransaction calls work?
We really think tha the inability to nest JPA.withTransaction calls is a bug because: a) it's not documented that we need not nest withTransaction calls; b) in real-life projects it's sometimes not possible to control third-party code that might call withTransaction while being executed within controller action which also requires @Transactional annotation or JPA.withTransaction call. It's possible to workaround such nasty cases, but it makes code very dirty & harder to maintain.
Any reply is deeply appreciated!
--
insign - simply e-business