content/basics---transactions.mdtext - tomee-site - Git at Google

 Title: Basics - Transactions
 One of the many benefits of EJB, is that transactions within the EJB
 container are generally managed entirely automatically.  Any EJB component
 will, by default, partake in that transaction.

 Here are some basic rules to understand about transactions.  Keep note that
 this is the default behaviour, and the system can be configured to behave
 differently, depending on the needs of your system, bean, or individual
 methods of your beans.

 <a name="Basics-Transactions-Participants"></a>
 ## Participants

 Various components and parts of the EJB system can be part of a
 transaction. Examples are

 1. Session bean
 1. Message Driven Bean
 1. EntityManager (a.k.a. Persistence context)

 <a name="Basics-Transactions-Behaviour"></a>
 ## Behaviour

 The basic default behaviours are
 1. A transaction starts at the beginning of the first EJB method call, in a
 chain of calls that are participating in the given transaction
 1. A transaction ends at the end of the first EJB method, in the same chain
 1. If a bean that has started a transaction, uses another bean, that bean
 will automatically use the same transaction as the calling bean.

 <a name="Basics-Transactions-Configuration"></a>
 ## Configuration

 You can configure your beans in a variety of ways.  Generally speaking, a
 transaction is started when a method is called, but can be configured using
 @TransactionAttribute(value = TransactionAttributeType.X), where X is one
 of...

 1. REQUIRED - the default, which is to start a transaction if one does not exist, but to use the existing one if it has already been started.
 1. REQUIRES_NEW - the transaction is created on every call, and ends when the call is completed.	Beans don't partake in transactions created by other parts of the system.
 1. MANDATORY - a transaction must always exist prior to the call, and it will be used.  It is an error otherwise
 1. NOT_SUPPORTED - component not included in the transaction
 1. SUPPORTS - transaction will be used if it exists, but will not be created if it does not exist
 1. NEVER - if a transaction exists, it is an error to call the method

 @TransactionAttribute applies to both methods and entire beans.  You may
 set one type of transaction behaviour (as seen above) on the bean, and a
 different one on a specific method of that same bean, which overrides the
 one configured for the overall bean.  For instance, maybe you want to make
 an audit entry in the database that you are about to attempt a credit card
 payment.  It really needs to be in it's own transaction so that it is
 IMMEDIATELY committed for audit purposes, if something goes wrong with the
 credit card payment.  So, perhaps you use MANDATORY on the bean, and
 REQUIRES_NEW on the method for audit logging.  As soon as the method that
 does the audit logging is complete, the transaction is committed, and the
 credit card payment transaction continues on it's way.
	Title: Basics - Transactions
	One of the many benefits of EJB, is that transactions within the EJB
	container are generally managed entirely automatically. Any EJB component
	will, by default, partake in that transaction.

	Here are some basic rules to understand about transactions. Keep note that
	this is the default behaviour, and the system can be configured to behave
	differently, depending on the needs of your system, bean, or individual
	methods of your beans.

	<a name="Basics-Transactions-Participants"></a>
	## Participants

	Various components and parts of the EJB system can be part of a
	transaction. Examples are

	1. Session bean
	1. Message Driven Bean
	1. EntityManager (a.k.a. Persistence context)

	<a name="Basics-Transactions-Behaviour"></a>
	## Behaviour

	The basic default behaviours are
	1. A transaction starts at the beginning of the first EJB method call, in a
	chain of calls that are participating in the given transaction
	1. A transaction ends at the end of the first EJB method, in the same chain
	1. If a bean that has started a transaction, uses another bean, that bean
	will automatically use the same transaction as the calling bean.

	<a name="Basics-Transactions-Configuration"></a>
	## Configuration

	You can configure your beans in a variety of ways. Generally speaking, a
	transaction is started when a method is called, but can be configured using
	@TransactionAttribute(value = TransactionAttributeType.X), where X is one
	of...

	1. REQUIRED - the default, which is to start a transaction if one does not exist, but to use the existing one if it has already been started.
	1. REQUIRES_NEW - the transaction is created on every call, and ends when the call is completed. Beans don't partake in transactions created by other parts of the system.
	1. MANDATORY - a transaction must always exist prior to the call, and it will be used. It is an error otherwise
	1. NOT_SUPPORTED - component not included in the transaction
	1. SUPPORTS - transaction will be used if it exists, but will not be created if it does not exist
	1. NEVER - if a transaction exists, it is an error to call the method

	@TransactionAttribute applies to both methods and entire beans. You may
	set one type of transaction behaviour (as seen above) on the bean, and a
	different one on a specific method of that same bean, which overrides the
	one configured for the overall bean. For instance, maybe you want to make
	an audit entry in the database that you are about to attempt a credit card
	payment. It really needs to be in it's own transaction so that it is
	IMMEDIATELY committed for audit purposes, if something goes wrong with the
	credit card payment. So, perhaps you use MANDATORY on the bean, and
	REQUIRES_NEW on the method for audit logging. As soon as the method that
	does the audit logging is complete, the transaction is committed, and the
	credit card payment transaction continues on it's way.