JPA and CMT -- Why Catching Persistence Exception is Not Enough?

Being in EJB and JPA world using CMT (Container Managed Transactions) is very comfortable. Just define few annotations to demarcate transaction boundary (or use the defaults) and that’s it – no fiddling with manual begin, commit or rollback operations. One way to rollback your transaction is to throw non-application exception (or application exception with rollback = true) from your EJB’s business method. It seems simple: if during some operation there is a possibility that an exception will be thrown and you don’t want to rollback your tx than you should just catch this exception and you’re fine....

March 10, 2013 · 5 min

Types of EntityManagers -- Application-managed EntityManager

JPA specification defines few types of EntityManagers / Persistence Contexts. We can have: extended and transactional-scoped EntityManagers, container-managed or application-managed EntityManagers. JTA or resource-local EntityManager, Besides the above distinction, we also have two main contexts in which EntityManager / Persistence Context can exist – Java EE and Java SE. Not every option is available for Java EE and not every is possible in Java SE. In the rest of the post I refer to the Java EE environment....

November 21, 2012 · 9 min

EJB 3.1 Interceptors -- Same Transaction, Same Principal

Few days ago I’ve created a simple interceptors spike-solution at Github. Its purpose was to show my colleagues that in the EJB’s interceptors you can implement a code that exists in the same transaction and the same security context as the called EJB business method. Moreover, you can benefit from all the dependency injection you need. This project uses the following resources injected by the Application Server: TransactionSynchronizationRegistry – used for getting current transaction key and checking if we’re in the same transaction (I’ve written about it e....

November 11, 2012 · 2 min

Am I in the same transaction? Am I using the same PersistenceContext?

Recently, I’ve bumped into few posts on StackOverflow where people tend to compare container managed EntityManager instances (so the one injected by the container) by invoking EntityManager#toString() method. I’ve felt that it’s fundamentally wrong to compare EntityManager instances without knowing how they’re managed by the JPA provider or the Server Application. And what if this behaviour differs between Application Server vendors? The JPA provider provides an implementation of EntityManager – that’s obvious....

November 23, 2011 · 4 min