What is JTA with container managed transaction advantage

Question

I use JavaEE 8 with OpenLiberty Application server .
in my project i try to use JTA over container managed transaction (BMT) in CRUD layer .
this is my example code :

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class SampleCRUD {

    @Inject
    private Logger logger;

    @PersistenceContext
    private EntityManager em;

    public void insertFood(Food food) {
        em.persist(food);
    }

    public void updateFood(Food food) {
        em.merge(food);
    }

    public Food selectFood(long id) {
        return em.find(Food.class, id);
    }

    public void deleteFood(long id) {
        em.remove(select(id));
    }
}      

and Food entity :

@Table
@Entity
@SequenceGenerator(name = "default_seq", sequenceName = "food_seq", allocationSize = 1)
public class Food extends BaseEntity {

    @Column(unique = true)
    private String name;
    

I want to understand :
is there any recommendation to select on database before sql insert/delete/update operations ?
I ask this question because in CMT mode can not catch Constraint or SQL exceptions on application .

in my example codes :

• need select before persist because duplicate key exception results in application sevrer .
• need select before remove because entity not found exception results in application server .

What is JTA with container managed transaction (CMT) advantage ?

Answer 1

the difference is who manages the transactions demarcations

if you manage it yourself (BEAN) you control the good and the error case (and you have to do a commit/rollback)

if you let it do the container any unhandled exception will cause a rollback implicitly and also the commits are ensured for you. So you simply need to implement the logic and the rest is done by JTA

So if you do not need any special handling on transactions the easiest way is to leave the transaction handling to the container

Answer 2

The problem that you raise here isn't due to container managed transactions so much as it is due to limitations of the JPA (Java Persistence Architecture) with respect to optimistic inserts. When you try to insert an entity that already exists, the JPA EntityManager per the JavaDoc will raise an error (EntityExistsException or PersistenceException with chained exception such as SQLIntegrityConstraintViolationException) and mark the transaction to be rolled back. That prevents you from being able to write application logic that traps the exception of an unsuccessful insert as part of a valid transaction that you want to commit. The programming model just doesn't let you do this. Whether you are using container managed transactions or application managed transactions is beside the point.

Depending on your business logic, it might be possible to partly work around the issue by forcing certain operations to run in a new transaction, in which case if it gets rolled back the invoker's transaction isn't impacted. This would look something like the following,

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public boolean insertFood(Food food) {
    try {
        em.persist(food);
        em.flush();
        return true;
    } catch (PersistenceException x) {
        if (x instanceof EntityExistsException
         || x.getCause() instanceof SQLIntegrityConstraintViolationException)
            return false;
        throw x;
    }
}

The obvious downside being that the operation is then no longer part of the invoker's transaction.

You mentioned the possibility of running a select/find before attempting the insert. The problem here will be when multiple threads overlap and both see nothing in the database and then both try the insert. The error will still occur, albeit less frequently. A pessimistic lock might help here.

Another option, if the database/JDBC driver permits it (doesn't force a rollback on unsuccessful insert), could be to forego the use of JPA and run the SQL commands directly via JDBC to the database.