¿Usaría AOP para la gestión de transacciones de base de datos?

Question

Hace un tiempo escribí una aplicación que usaba Spring AOP para definir qué métodos eran transaccionales. Ahora estoy pensando en qué tan buena idea fue esta; Me han golpeado varias veces después de un refactor menor (cambiando las firmas de los métodos, etc.) que, por supuesto, no se hace evidente hasta que algo sale mal (y tengo una base de datos lógicamente inconsistente).

Estoy interesado en algunas cosas:

1. ¿Otras personas han decidido volver a la administración explícita de transacciones (por ejemplo, a través de las anotaciones de @Transactional )?
2. ¿Existen herramientas útiles que pueda usar como parte de un proceso de compilación para ayudar a identificar si algo se ha roto " " ;?
3. Si las personas están usando AOP para administrar transacciones, ¿qué pasos están tomando para evitar los errores que he cometido?

Estoy usando IntelliJ IDEA que le permite navegar por métodos decorados y refactorizará Spring XML junto con cambios de nombre de método, pero esto no siempre es suficiente (agregar un parámetro a un método en el un lugar incorrecto puede afectar si un aspecto se dispara, por ejemplo)

Answer 1

Actualmente estoy usando la gestión declarativa de transacciones en los dos proyectos Java en los que trabajo, especificando qué métodos necesitan el alcance transaccional con la anotación @Transactional . En mi opinión, es una buena combinación de flexibilidad y solidez: puede ver qué métodos tienen un comportamiento transaccional a través de una simple búsqueda de texto, puede ajustar los atributos de aislamiento y propagación a mano si es necesario, y la cantidad adicional de escritura es prácticamente negligente .

En uno de esos proyectos, tengo seguridad / registro implementado a través de aspectos y ocasionalmente me he topado con los mismos obstáculos que usted al cambiar el nombre de un método o cambiar las firmas. En el peor de los casos, perdí algunos datos de registro de los usuarios que accedieron a los contratos, y en una versión, algunos roles de usuario no pudieron acceder a todas las funciones de la aplicación. Nada importante, pero, en lo que respecta a las transacciones de la base de datos, creo que simplemente no vale la pena, y es mejor escribir el bit @Transactional usted mismo. La primavera hace la parte difícil, de todos modos.

Answer 2

Con respecto a (1): Encontré a @Transactonal una solución más práctica en todos los proyectos en los que trabajé en los últimos años. Sin embargo, en algunos casos muy específicos, también tuve que usar Spring AOP para permitir el uso de más de una conexión JDBC / TransactionManager porque @Transaction está vinculado a un solo administrador de transacciones.

Con respecto a (2): Dicho esto, en un escenario mixto, hago muchas pruebas automatizadas para encontrar un código posiblemente roto. Utilizo AbstractTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests de Spring para crear mis pruebas. Ha sido una solución muy efectiva hasta ahora.

Answer 3

Tiendo a ser más purista, pero trato de mantener toda la administración de transacciones más allá de una simple confirmación automática, dentro de la base de datos en sí. La mayoría de las bases de datos son excelentes para manejar la gestión de transacciones, después de todo, es uno de los componentes clave de lo que una base de datos debe hacer.