I have a Spring-managed service method to manage database inserts. It contains multiple insert statements.
@Transactional public void insertObservation(ObservationWithData ob) throws SQLException { observationDao.insertObservation(ob.getObservation()); // aop pointcut inserted here in unit test dataDao.insertData(ob.getData()); }
I have two unit tests which throw an exception before calling the second insert. If the exception is a RuntimeException, the transaction is rolled back. If the exception is a SQLException, the first insert is persisted.
I'm baffled. Can anyone tell me why the transaction does not roll back on a SQLException? Can anyone offer a suggestion how to manage this? I could catch the SQLException and throw a RuntimeException, but that just seems weird.
RollbackException exception is thrown when the transaction has been marked for rollback only or the transaction has been rolled back instead of committed. This is a local exception thrown by methods in the UserTransaction , Transaction , and TransactionManager interfaces.
SQLException comes under Runtime exception because errors comes under Unchecked Exceptions.
The @Transactional annotation makes use of the attributes rollbackFor or rollbackForClassName to rollback the transactions, and the attributes noRollbackFor or noRollbackForClassName to avoid rollback on listed exceptions. The default rollback behavior in the declarative approach will rollback on runtime exceptions.
Default rollback policy in Spring Framework is set to automatic rollback, but only when unchecked exception is being thrown from the method annotated with @Transactional annotation. When checked exception is being thrown from the method, transaction is not being rolled back.
This is defined behaviour. From the docs:
Any
RuntimeException
triggers rollback, and any checked Exception does not.
This is common behaviour across all Spring transaction APIs. By default, if a RuntimeException
is thrown from within the transactional code, the transaction will be rolled back. If a checked exception (i.e. not a RuntimeException
) is thrown, then the transaction will not be rolled back.
The rationale behind this is that RuntimeException
classes are generally taken by Spring to denote unrecoverable error conditions.
This behaviour can be changed from the default, if you wish to do so, but how to do this depends on how you use the Spring API, and how you set up your transaction manager.
For @Transactional
, by default, rollback happens for runtime, unchecked exceptions only. Thus, your checked exception SQLException
does not trigger a rollback of the transaction; the behavior can be configured with the rollbackFor
and noRollbackFor
annotation parameters.
@Transactional(rollbackFor = SQLException.class) public void insertObservation(ObservationWithData ob) throws SQLException { observationDao.insertObservation(ob.getObservation()); // aop pointcut inserted here in unit test dataDao.insertData(ob.getData()); }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With