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