Why Does test4 Transaction Roll Back? Uncovering Spring Data JPA Mysteries

Why It Doesn't Roll Back

Many readers tried to verify the claim that the transaction "won't roll back" and got it wrong for three main reasons:

Using MyISAM instead of InnoDB, which does not support transactions.

Using MyBatis or missing JPA/JSR‑303 validation annotations, so the scenario cannot be reproduced.

Defining the transactional method with a non‑public visibility, which prevents Spring from applying the transaction proxy.

These mistakes stem from not reading the problem statement carefully and lacking solid transaction fundamentals.

Why a Catch Block Still Triggers Rollback

The key exception is a javax.validation.ConstraintViolationException, which originates from Bean Validation (JSR‑303). Although some think it is not a RuntimeException, it actually extends RuntimeException, so Spring marks the transaction for rollback.

javax.validation.ConstraintViolationException: Validation failed for classes [com.didispace.chapter310.User] during persist time ...
    at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:140)
    ...
    at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:271)
    at org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:98)

Since Spring Data JPA and Hibernate Validator are used, Bean Validation is automatically invoked during the pre‑persist, pre‑update, and pre‑remove lifecycle events. When validation fails and throws ConstraintViolationException, the current transaction is marked for rollback.

Source Code Walkthrough

To see exactly what happens, follow the stack trace to the line where the error occurs (line 532, tx.commit()). Setting breakpoints there and at the surrounding catch block helps observe the transaction state.

The next relevant class is org.hibernate.engine.transaction.internal.TransactionImpl, where the commit logic resides.

Further debugging shows the validation exception being thrown around line 271, confirming the rollback cause.

Takeaway

Understanding the underlying transaction mechanics and Bean Validation integration is essential. When you encounter similar issues, inspect the exception type and ensure your transactional method is correctly defined, uses a transactional‑supporting storage engine, and follows proper JPA conventions.