Propagation (Transaction Propagation attributes)
Propagation: The key attribute determines which methods the agent should add transaction behavior to. The most important part of this attribute is the propagation behavior. You may use the following options: PROPAGATION_REQUIRED– Support the current transaction, or create a new one if there are none. This is the most common choice. PROPAGATION_SUPPORTS– Supports the current transaction, and executes non-transactionally if there is no transaction currently. PROPAGATION_MANDATORY– The current transaction is supported, and an exception is thrown if there is no transaction currently. PROPAGATION_REQUIRES_NEW– Creates a transaction, and suspends the current transaction if one exists. PROPAGATION_NOT_SUPPORTED– Executes an operation in a non-transactional manner, and suspends the current transaction if one exists. PROPAGATION_NEVER– Executes non-transactionally, throws an exception if a transaction currently exists.
1: PROPAGATION_REQUIRED adds that the transaction currently being executed is not in another transaction, and a new transaction is created, for example, MethodB transaction level is defined as PROPAGATION_REQUIRED, and the transaction level for ServiceA.methodA is PROPAGATION_REQUIRED. The ServiceB. MethodB sees that it is already running inside the ServiceA. MethodA transaction and does not start a new transaction. If servicea. methodA runs and finds that it is not in a transaction, it allocates a transaction to itself. This way, if an exception occurs in Servicea. methodA or anywhere else in Serviceb. methodB, the transaction will be rolled back. Even if the transaction for ServiceB. MethodB has been committed, but ServiceA. MethodA fails to roll back, ServiceB. MethodB also rolls back
2: PROPAGATION_SUPPORTS Runs as a transaction if it is currently in a transaction, or non-transactional if it is no longer in a transaction
3: PROPAGATION_MANDATORY Must be run in a transaction. That is, it can only be called by one parent transaction. Otherwise, he throws an exception
4: PROPAGATION_REQUIRES_NEW This one is tricky. For example, the transaction level of Servicea. methodA is PROPAGATION_REQUIRED and the transaction level of serviceB. methodB is PROPAGATION_REQUIRES_NEW, MethodB (); methodA (); methodA (); methodA (); The transaction differs from PROPAGATION_REQUIRED in the rollback level of the transaction. Since ServiceB. MethodB is a new transaction, there are two different transactions. If ServiceB. MethodB has been committed, then ServiceA. MethodA fails to roll back. If serviceb.methodb fails to roll back, the Servicea.methoda transaction may still commit if the exception it throws is caught by Servicea.methoda.
5: PROPAGATION_NOT_SUPPORTED The current transaction is not supported. For example, the transaction level for Servicea. methodA is PROPAGATION_REQUIRED, and the transaction level for Serviceb. methodB is PROPAGATION_NOT_SUPPORTED, MethodA transaction suspends when ServiceB. MethodB is executed. MethodA transaction suspends when ServiceB. MethodA transaction is executed.
6: PROPAGATION_NEVER cannot run in a transaction. If ServiceA.methodA’s transaction level is PROPAGATION_REQUIRED and ServiceB.methodB’s transaction level is PROPAGATION_NEVER, then ServiceB.methodB throws an exception.
Savepoint is the key to PROPAGATION_NESTED. The difference between “requires_new” and “PROPAGATION_REQUIRES_NEW” is that a new transaction, PROPAGATION_REQUIRES_NEW, will be independent of its parent, whereas a Nested transaction is dependent on its parent, and its commit must be committed with its parent. That is, if the parent transaction finally rolls back, it will also roll back. And the advantage of Nested transactions is that he has a savepoint. ***************************************** ServiceA {
/** * Transaction attributes are configured as PROPAGATION_REQUIRED */ void methodA() {try {// SavePoint serviceb.methodb (); // Execute other services, such as servicec.methodc (); }}
} * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * that is ServiceB methodB failure rollback, then ServiceA. MethodA will roll back to the savepoint point, MethodA can select another branch, such as Servicec. methodC, and continue to try to complete its transaction. However, this transaction is not defined in the EJB standard.