por qué la transacción se retrotrae a RuntimeException pero no a SQLException

Question

Tengo un método de servicio administrado por Spring para administrar las inserciones de la base de datos. Contiene múltiples instrucciones de inserción.

@Transactional 
public void insertObservation(ObservationWithData ob) throws SQLException 
{ 
    observationDao.insertObservation(ob.getObservation()); 
      // aop pointcut inserted here in unit test 
    dataDao.insertData(ob.getData()); 
} 

Tengo dos pruebas de unidad que arrojan una excepción antes de llamar al segundo inserto. Si la excepción es una RuntimeException, la transacción se revierte. Si la excepción es una SQLException, la primera inserción se conserva.

Estoy desconcertado. ¿Alguien puede decirme por qué la transacción no retrocede en una SQLException? ¿Alguien puede ofrecer una sugerencia sobre cómo manejar esto? Pude captar la SQLException y lanzar una RuntimeException, pero eso parece extraño.

Answer 1

Esto es un comportamiento definido. Desde el docs:

Cualquier RuntimeException desencadena rollback, y cualquier excepción revisada no lo hace.

Comportamiento habitual en todas las API de transacciones de Spring. De forma predeterminada, si se lanza un RuntimeException desde el código transaccional, la transacción se retrotraerá. Si se lanza una excepción marcada (es decir, no un RuntimeException), la transacción no se revertirá.

El razonamiento detrás de esto es que las clases RuntimeException generalmente son tomadas por Spring para denotar condiciones de error irrecuperables.

Este comportamiento puede cambiarse del predeterminado, si así lo desea, pero cómo hacerlo depende de cómo use Spring API y de cómo configure su administrador de transacciones.

Answer 2

Spring hace un uso extenso de RuntimeExceptions (incluido el uso de DataAccessExceptions para ajustar SQLExceptions o excepciones de ORM) para los casos en que no hay recuperación de la excepción. Supone que desea utilizar excepciones comprobadas para los casos en que una capa superior al servicio necesita ser notificada de algo, pero no desea que se interfiera la transacción.

Si está utilizando Spring, también puede utilizar sus bibliotecas jdbc-wrapping y DataAccessException-tralating, reducirá la cantidad de código que debe mantener y proporcionará excepciones más significativas. Además, tener una capa de servicio arrojando excepciones específicas de la implementación es un mal olor. La forma anterior a Spring fue crear excepciones controladas por implementación que incluyan excepciones específicas de la implementación, esto dio como resultado una gran cantidad de trabajo ocupado y una base de código inflada. El camino de la primavera evita esos problemas.

Si desea saber por qué Spring eligió hacer que las cosas funcionen de esta manera, es probablemente porque usan AOP para agregar el manejo de transacciones. No pueden cambiar la firma del método que están envolviendo, por lo que las excepciones comprobadas no son una opción.