The container managed transaction scopes

Required

creates a new transaction if there isn’t one already, otherwise join it.

RequiresNew

If an existing transaction, pauses it, the start a new transaction, do the work and commit/rollback, then resume the existing transaction. If no existing transaction just starts and stops one for this method. Note: This is not a nested transaction as the inner one has no effect on the outer.

Mandatory

Uses existing transaction, throws a TransactionRequiredException if no transaction already.

NotSupported

Stops the current transaction, make the call and carry on – may improve performance.

Supports

Uses a transaction if there is one, otherwise doesn’t bother.

Never

Throws a RemoteException if a transaction exists, otherwise it carries on fine and doesn’t start a transaction.

ACID

Atomic: All or nothing – if any task fails the transaction is rolled back; if all complete the transaction is committed
Consistent: The state of the system must reflect the real world
Isolated: The data involved in a current transaction cannot be affected by other transactions until the current transaction completes.
Durable: The transactional system must ensure that the data is persistent before the transaction can be considered to be complete

Note

Bean Managed Transactions (BMT) is Session Bean and MDB only!
CMT is preferable but BMT gives finer transactional control. CMT can be influenced by context.setRollbackOnly()

SessionSynchronization

Use the SessionSynchronization interface if you want to be informed when the transactions are being committed/rolledback (only on Stateful Session Beans). It adds additional lifecycle methods.