Explicit Transaction Management
Using bean-managed transaction demarcation, under which two circunstances must the container roll back a transaction? (Choose two)
- A stateful session bean invokes UserTransaction.getRollbackOnly
- A stateful session bean throws an uncaught application exception from a business method
- A stateful session bean begins a transaction in a business method but does NOT complete it before returning
- A stateless session bean begins a transaction in a business method but does NOT complete it before returning
- A message-driven bean begins a transaction in a message listener method but does NOT complete it before returning
Veamos a las opciones una por una, para ver quien miente y quien dice la verdad. El método getRollbackOnly retorna TRUE si la transacción actual ha sido marcada para un rollback. Esta información puede utilizarse para evitar ejecutar código que ya no va a ser "commited" después de todo. Por eso, la primera no va. Además, getRollbackOnly y setRollbackOnly son usados por beans CMT (container-managed transaction), lo que refuerza aún más nuestra afirmación que la primera no va.
Las excepciones de aplicación son lanzadas por lo general en respuesta a un error de lógica de negocio (y no por un error de sistema). Las excepciones de aplicación son lanzadas directamente al cliente sin ser empaquetadas en una excepción EJBException. Por defecto, no causan un rollback en la transacción (aunque esto puede ser modificado) , por lo que la segunda alternativa tampoco es cierta.
Con los stateless session beans, las transacciones administradas mediante UserTransaction (como se trata de un BMT es así) deben ser iniciadas y completadas dentro de un mismo método. De no hacerlo, se lanzaría una excepción que nos llevaría al rollback, por lo que la cuarta es correcta. Sin embargo, con los stateful session beans una transacción puede comenzar en un método y recibir el commit en otro método, debido a que los beans stateful son usados sólamente por un cliente. Entonces, la tercera miente.
Para finalizar, los message driven beans también tienen la opción de administrar sus propias transacciones. En el caso de los MDB's, el alcance de la transacción debe comenzar y terminar en el método onMessage(). Por eso, la quinta también va.
En síntesis, nos quedamos con la cuarta y la quinta opción.
Pregunta tomada de ExamWorx
Publicar un comentario