Alguien añade Transactional a un método y parece que no funciona. ¿Cuáles son los motivos habituales?

La anotación se implementa con un proxy, así que solo se aplica cuando la llamada entra al bean desde fuera. Una llamada desde otro método de la misma clase se salta el proxy por completo, y esa es la causa más común. Otras razones: el método no es público, la excepción lanzada es checked y por defecto no dispara rollback, el bean se creó fuera del contenedor, o hacía falta una transacción nueva y la propagación se dejó en required.

Nueve de cada diez veces es autoinvocación. Spring envuelve el bean en un proxy, y la transacción empieza cuando quien llama pasa por ese proxy, así que si un método público de la misma clase llama directamente al método anotado, la llamada nunca sale del objeto y no empieza ninguna transacción. El arreglo es mover el método a otro bean o inyectar el bean en sí mismo, y el arreglo honesto suele ser que la frontera estaba mal puesta de todas formas. Después compruebo lo básico: el método debería ser público, el bean tiene que estar gestionado por Spring y no creado con new, y la regla de rollback pilla a la gente porque por defecto solo se hace rollback ante excepciones unchecked, así que una excepción checked confirma salvo que especifique rollbackFor. También miro la propagación, ya que el trabajo que debe sobrevivir al rollback de quien llama necesita requires new, y eso ocupa una segunda conexión, lo que importa si el pool es pequeño. Y mantengo las transacciones cortas: nada de llamadas HTTP, ni publicación de mensajes, ni esperas dentro de una, porque retener una conexión de base de datos mientras llamas a un tercero es como se agota un pool.