--------------------------------------------------
TRANSACTION
--------------------------------------------------
1. When an instance attempts to start a transaction using the begin() method of the javax.transaction.
UserTransaction interface while the instance has not committed the previous transaction,
the Container must throw the javax.transaction.NotSupportedException in the
begin() method

2. The Container must throw the java.lang.IllegalStateException if an instance of a bean
with bean-managed transaction demarcation attempts to invoke the setRollbackOnly() or
getRollbackOnly() method of the javax.ejb.EJBContext interface.

3. If an instance of an enterprise bean with container-managed transaction demarcation attempts
to invoke the getUserTransaction() method of the EJBContext interface, the Container must throw the
java.lang.IllegalStateException.

4. When the container starts a transaction, it is responsible for controlling the transaction when it
receives an exception. If the bean method throws an application exception but does not mark the
transaction for rollback, the container will commit the transaction before re-throwing the
application exception to the client. If the bean method marks the transaction for rollback,
the container will roll back the transaction before re-throwing the application exception to the client.

5. The container always discards an enterprise bean instance because the bean may end up in an inconsistent
state as a result of the non-application exception thus becoming unsafe for further use.


Discarding the bean prevents both the container and the client from further invoking methods on the bean.


javax.ejb.TransactionRolledbackLocalException (subclass of javax.ejb.EJBException) indicates to the local
client that the transaction has definitely been marked for rollback. Attempting to continue with the
transaction is pointless because the transaction cannot be committed.


Unlike business methods of a session or entity bean, message-driven bean methods do not throw
application exceptions.

The container is responsible for performing any clean up actions before throwing a non-application
exception.


The container is not responsible for committing or rolling back transactions that have been initiated
by the client.

6. The container is only responsible for rolling back a system exception for an message-driven bean with
container-managed transaction demarcation and when the bean method runs in the context of a transaction
started by the container.


A transaction is not rolled backed by the container as a result of a system exception thrown when the
transaction runs with an unspecified transaction context and also when a bean is declared with
bean-managed transaction demaraction.

7. If a remote client in a transaction context invokes a business method on a bean with container-managed
transaction and the bean throws a non-application exception, the transaction is marked for rollback.
The client then receives javax.transaction.TransactionRolledbackException (subclass of java.rmi.RemoteException)
which indicates that the transaction has definitely been marked for rollback.

8. An application assembler cannot affect transactional behaviour for enterprise beans that use bean-managed
transaction demarcation. The application assembler can only affect transactional behaviour of beans that
use container-managed transaction demarcation.

9. An entity beans can only use the CMT (IS THIS NOT CMP ???????????????????????)

10. Only Session Beans and Message driven beans can be designed to use Bean Managed Transaction demarcation.
Entity beans can only be designed to use Container Managed Transaction demarcation.

11. getRollbackOnly() and setRollbackOnly() should be ONLY invoked from methods having Required, RequiresNew,
Mandatory attribute. Otherwise it throws an IllegalStateException.

12. The Enterprise JavaBeans architecture supports FLAT transactions.
A flat transaction cannot have any child (nested) transactions.

13. If an enterprise bean implements the javax.ejb.SessionSynchronization interface, the Application Assembler
can specify only the following values for the transaction attributes of the bean's methods: Required,
RequiresNew,or Mandatory. This restriction is necessary to ensure that the enterprise bean is invoked only
in a transaction.
If the bean were invoked without a transaction, the Container would not be able to send the transaction
synchronization calls.