La Spring @Transactional Anotación De Las Mejores Prácticas

En general estoy de acuerdo con los demás que indica que las transacciones son normalmente comienza en el nivel de servicio (dependiendo de la granularidad que se requieren, por supuesto).

Sin embargo, en el medio tiempo, también comenzó a incluir el @Transactional(propagation = Propagation.MANDATORY) de mi capa DAO (y de otras capas que no están autorizados para iniciar las transacciones, sino que requieren los ya existentes), porque es mucho más fácil detectar los errores de donde usted ha olvidado de iniciar una transacción en la llamada (por ej. el servicio). Si el DAO es anotado con la obligación de propagación obtendrá una excepción que indica que no hay ninguna transacción activa cuando se invoca el método.

También tengo un test de integración donde puedo comprobar todos los granos (frijol post processor) para esta anotación y error si hay un @Transactional anotación con la propagación de los otros no Obligatorios en un bean que no pertenecen a la capa de servicios. De esta manera me aseguro de no inicio de transacciones en la capa equivocada.

Transaccional Anotaciones deben ser colocados alrededor de todas las operaciones que son inseparables.

Por ejemplo, la llamada es "cambiar contraseña". Que consta de dos operaciones

1. Cambio de la contraseña.
2. Auditar el cambio.
3. Correo electrónico del cliente de que ha cambiado la contraseña.

Así que en el anterior, si en la auditoría falla, entonces el cambio de contraseña también no? Si es así, entonces la transacción debe ser de alrededor de 1 y 2 (de modo que en la capa de servicio). Si el correo electrónico no (probablemente debería haber algún tipo de fail safe en esto, así que no fallará), a continuación, debe revertir el cambio de la contraseña y de la auditoría?

Estos son el tipo de preguntas que deben plantearse a la hora de decidir dónde poner el @Transactional.

La respuesta correcta es tradicional en la Spring de arquitecturas es el lugar de la semántica transaccional en las clases de servicios, por las razones que otros ya hemos descrito.

Una tendencia emergente en la Spring es hacia domain-driven design. Spring Roo ejemplifica la tendencia bien. La idea es hacer que el dominio objeto de POJOs mucho más ricos de lo que son típicos en la Spring de arquitecturas (por lo general son anémicos), y, en particular, para poner de transacciones y persistencia de la semántica de los objetos de dominio de sí mismos. En los casos en donde todo lo que se necesita es sencillo operaciones CRUD, la web de los controladores de operar directamente en el objeto de dominio POJOs (funcionan como entidades en este contexto), y no hay ningún nivel de servicio. En casos donde hay algún tipo de coordinación necesarios entre los objetos de dominio, usted puede tener un servicio de frijol de manejar que, con @Transacción como por la tradición. Puede establecer la propagación de la transacción en el dominio de los objetos a algo como NECESARIOS de modo que el dominio, uso de objetos de cualquiera de las transacciones existentes, tales como las transacciones que se iniciaron en el servicio de frijol.

Técnicamente esta técnica hace uso de AspectJ y . Roo utiliza AspectJ entre las definiciones de tipo de separar la entidad semántica (transacciones y persistencia) de dominio objeto material (básicamente, los campos y los métodos de negocio).

En el caso normal sería anotar en un servicio de nivel de la capa, pero esto realmente depende de sus requerimientos.

Anotar en una capa de servicio resultará en más transacciones de la anotación en el DAO de nivel. Dependiendo del nivel de aislamiento de transacción que pueden youse problemas, como transacciones concurrentes no ver otros cambios en la eg. REPEATABLE READ.

Anotar en el DAOs mantendrá las transacciones lo más corto posible, con el inconveniente de que la funcionalidad de su capa de servicio es el de exponer a no ser hecho en una sola (rollbackable) de la transacción.

No tiene sentido para anotar dos capas si la propagación de modo está ajustado por defecto.