| = Basics - Transactions |
| :index-group: Unrevised |
| :jbake-date: 2018-12-05 |
| :jbake-type: page |
| :jbake-status: published |
| |
| 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. |
| |
| == Participants |
| |
| Various components and parts of the EJB system can be part of a |
| transaction. Examples are |
| |
| [arabic] |
| . Session bean |
| . Message Driven Bean |
| . EntityManager (a.k.a. Persistence context) |
| |
| == 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. |
| |
| == 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... |
| |
| [arabic] |
| . 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. |
| . 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. |
| . MANDATORY - a transaction must always exist prior to the call, and it |
| will be used. It is an error otherwise |
| . NOT_SUPPORTED - component not included in the transaction |
| . SUPPORTS - transaction will be used if it exists, but will not be |
| created if it does not exist |
| . 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. |