SCBCD: Apuntes tácticos I


(Imagen: Paul Gauguin - Cristo amarillo)

Aquí unas notas de emergencia para leer antes de dar el SCBCD. Están basadas en lo publicado por Raghavendra Balgi, cuyas notas he traducido y aumentado. Ah! He omitido las porciones de descriptor de despliegue XML porque es laborioso ponerlas en un post. Con esas consideraciones...prosigo:

  • Los MDB's (message-driven beans) pueden usar como atributos de transacción REQUIRED y NOT_SUPPORTED. Los métodos timeout
  • callback REQUIRED, REQUIRES_NEW, NOT_SUPPORTED, y los session beans REQUIRED, REQUIRES_NEW, MANDATORY
  • Sólamente los session beans y los MDB's pueden usar transacciones administradas por bean (BMT)
  • AL utilizar BMT, no se deben utilizar los métodos setRollbackOnly y getRollbackOnly de EJBContext. En ese caso, se deben usar
  • los métodos getStatus y rollback de userTransaction.
  • Las transacciones están disponibles para métodos de negocio, métodos message listener (ej. onMessage en MDB's), métodos
  • timeout y métodos de interceptores.
  • Si un session bean stateless no le da COMMIT o ROLLBACK a la transacción antes de finalizar el método, el contenedor marcará
  • la transacción para rollback y se lanzará la excepción EJBException al cliente.
  • Atributos de transacción para beans CMT (transacciones manejadas por contenedor)
  • REQUIRED: Se crea una transacción si es que una no existe ya
  • REQUIRES_NEW: Se se crea una nueva transacción (si una ya existe, se suspende)
  • NEVER: Si existe una transacción, te devuelve una EJBException
  • SUPPORTS: Si existe la usa, y si no es así no se molesta en crear una nueva.
  • NOT_SUPPORTED: De existir una transacción, la suspende antes de invocar al método.
  • MANDATORY: De no existir una transacción se lanza EJBTransactionRequiredException
  • Los beans CMT no deberían usar UserTransaction
  • El descriptor de despliegue no puede ser usado poara sobre-escribir el tipo de transacción asociado al bean
  • El atributo de transacción por defecto es REQUIRED, y el tipo de transacción por defecto es CONTAINER
  • Los stateful session beans que son CMT pueden implementar la interfaz SessionSynchronization (afterBegin, beforeCOmpletition y afterCompletition)
  • Las excepciones de aplicación pueden ser especificadas en la interfaz de negocio, métodos message listener o en endpoints de webservice
  • Las excepciones de aplicación deben extender java.lang.Exception o java.lang.RuntimeException pero no de java.rmi.RemoteException
  • Se consideran excepciones de aplicacióna javax.ejb.CreateException, FinderException y RemoveException
  • Una excepción de aplicación es pasada al cliente tal cual
  • Una excepción de aplicación no causa un rollback en la transacción (a menos que sea especificado con el elemento "rollback" de la anotación @ApplicationException)
  • Una excepción de sistema es una excepción que hereda de RemoteException o de RuntimeException, cuando no es definida como excepción de aplicación.
  • Si un session bean con atributo de transacción REQUIRED/MANDATORY/SUPPORTS (con transacción del cliente) lanza una excepción de aplicación, el cliente recibe esta excepción de aplicación.
  • Si un session bean con atributo de transacción REQUIRED/MANDATORY/SUPPORTS (con transacción del cliente) lanza una excepción que no es de aplicación, el cliente recibe EJBTransactionRolledbackException
  • Si un session bean con REQUIRED/REQUIRES_NEW (con transacción del contenedor) lanza una excepción de aplicación, el cliente recibe una excepción de aplicación.
  • Si un session bean con atributo de transacción REQUIRED/REQUIRES_NEW (con transacción del contenedor) lanza una excepción que no es de aplicación, el cliente recibe EJBException, y la instancia es descartada.
  • Si una existe transacción, y se lanza una excepción de aplicación, el cliente recibe una excepción de aplicación.
  • Si no existe transacción, y se lanza una excepción que no es de aplicación, el cliente recibe EJBException, y se descarta la instancia.
  • Un bean puede implementar TimedObject e implementar el método ejbTimeout(Timer) o anotar un método con @Timeout (public void method(Timer)) para especificar un método Timeout Callback
  • Los métodos createTimer de TimerService especifican la duración en milisegundos.
  • Para seguridad programática, se utilizan los métodos getCallerPrincipal() e isCallerInRole(String) de EJBContext

Publicar un comentario