Las transacciones manejadas por el contenedor EJB soportan distintos valores para su anotación @TransactionAttribute:
TransactionAttributeType.REQUIRED: se trata del valor por defecto si no se emplea la anotación para indicar el atributo transaccional. Se interpreta como que el método anotado con este valor tiene que ser ejecutado dentro de una transacción. Más especificamente, cuando existe una transacción activa y el método es invocado desde esa transacción, automáticamente entra a formar parte de la misma. Si por el contrario, es invocado desde un contexto no transaccional, se crea una nueva transacción para ejecutar el método. En caso de fallo, cuando se revierte la transacción, el rollback siempre afectará a los métodos anotados como "REQUIRED".
 |
| Supongamos que antes de llamar a crearDetalleEmpleado() para crear un ojbeto DetalleEmpleado se crea un objeto Empleado general. Tanto si se produce un error antes como después de haber creado un objeto DetalleEmpleado con la llamada a crearDetalleEmpleado(), el objeto DetalleEmpleado jamás se construirá porque la operación entra a formar parte de la transacción original de crearEmpleado(), de tal manera que si ya hubiera sido instanciado se revertirá la operación y se eliminará la instancia. |
- TransactionAttributeType.REQUIRES_NEW: implica que siempre se creará una nueva transacción para el método anotado con este valor de atributo independientemente de si se invoca desde un contexto transaccional o no.
 |
| Supongamos que se crea un objeto Empleado antes de invocar a crearDepartamento(). Al invocar a crearDepartamento() se crea una instancia de Departamento que posteriormente será encapsulada en el objeto Empleado. Si se produjese algún fallo en el método crearEmpleado() justo después de la llamada a crearDepartamento(), la instacia de Departamento no se eliminaría porque ha sido creada en una transacción independiente a la de crearEmpleado() que ha culminado con éxito. |
- TransactionAttributeType.SUPPORTS: supone la propagación del estado transaccional del contexto que invoca al método anotado con este valor. Esto es, si el método es invocado desde una transacción activa, entonces entrará a formar parte de esa transacción y también se verá afectado por el rollback en caso de fallo. En cambio, si el método es invocado normalmente, sin un contexto transaccional, entonces su código también se ejecutará normalmente sin formar parte de ninguna transacción.
TransactionAttributeType.NOT_SUPPORTED: se emplea en situaciones donde determinadas tareas no pueden ejecutarse dentro de una transacción. Así, si el método anotado con este valor de atributo es invocado desde una transacción activa, la transacción es pausada justo antes de la invocación del método y reanudada tras su ejecución. En caso de una invocación desde un contexto no transaccional, el método se ejecutará normalmente fuera de cualquier transacción.
 |
| El ejemplo más ilustrativo de operaciones que no pueden ser incluidas en una transacción es el envío de un email, por tratarse de una tarea de naturaleza asíncrona. En este caso, la operación de registro del usuario debe ser pausada antes de enviar el email y reanudada justo después, pero en ningún caso el envío del email entra a formar parte de la transacción de registerUser() |
- TransactionAttributeType.MANDATORY: sirve para asegurarse de que el método anotado con este valor va a ejecutarse dentro de una transacción pero a diferencia de otros valores del atributo lanza una excepción si es invocado desde un contexto no transaccional.
 |
| Si llevamos a cabo una transferencia de capital que supone dos operaciones: deducir el capital de una cuenta origen y añadirlo a una cuenta destino, ambas operaciones deben necesariamente ejecutarse formando parte de una transacción; en caso contrario, se lanzará una excepción. |
- TransactionAttributeType.NEVER: se emplea en raras ocasiones. Permite que cuando desde una transacción activa se invoca un método anotado con este valor de atributo, automáticamente se lance una excepción.
