Spring transaction Type Cheung Solution

 

You may see this definition often in spring:

<prop key= "load*" >propagation_required,readonly</prop><prop key= "store*" >PROPAGATION_REQUIRED </prop>

It is estimated that a lot of friends have not yet figured out the meaning of the value of the inside, carefully read the following should know what the situation below should use what kind of statement. ^_^

Common transaction types in spring: propagation_required--supports the current transaction, and creates a new transaction if there are currently no transactions. This is the most common choice. propagation_supports--supports the current transaction and executes it in a non transactional manner if there are currently no transactions. propagation_mandatory--supports the current transaction and throws an exception if there are currently no transactions. propagation_requires_new--creates a new transaction and suspends the current transaction if there is currently a transaction. propagation_not_supported--performs an operation in a non transactional manner and suspends the current transaction if there is a current transaction. propagation_never--executes in a non transactional manner and throws an exception if there is a current transaction. Propagation_required a similar operation. propagation_nested--executes within a nested transaction if a transaction is currently present. If there are currently no transactions, the

(The figure AD and BC represent two transactions, and 1,2,3 represents three stages of transaction execution.) It's a little rough, sort of like "divine".

There are two requirements for scenarios that use nested transactions:

A transaction BC is required to commit with transaction ad, that is, as a child transaction of transaction AD, the transaction BC commits only if the transaction ad succeeds at commit (Phase 3 succeeds). This requirement is simply called "Joint success". This propagation_required can be done. A rollback that requires a transaction BC does not (unconditionally) affect the commit of transaction AD. This requirement is simply called "Quarantine failure." This propagation_requires_new can be done.

Using propagation_required satisfies demand 1, but the rollback of the child transaction BC will unconditionally make the parent transaction ad rollback and not meet the requirement 2.

Using propagation_requires_new satisfies demand 2, but a child transaction (which should not be called a child transaction) is a completely new transaction context, and the parent transaction (which should not be referred to as the parent transaction) has no effect on the success of BC and does not meet the requirement of 1.

At the same time to meet the above two requirements will be used propagation_nested. Propagation_nested set the SavePoint (critical) when transaction ad executes to point B.

When the BC transaction succeeds in the commit, the propagation_nested behaves the same as propagation_required. Only when transaction ad succeeds in a commit at D point, the transaction BC is really commit, and if Phase 3 performs an exception that results in transaction ad rollback, the transaction BC is also rollback together, thus satisfying the "federated success".

When Phase 2 performs an exception, resulting in a BC transaction rollback, "Quarantine failure" is met because the SAVEPOINT,AD transaction can be set up to rollback or resume Phase 3 with the BC and preserve phase 1 execution results.

Of course, to be clear, the definition of a transactional propagation policy is within the scope of the Declaration or transaction management (first, defined in the EJB CMT specification, the Spring transaction framework complements the propagation_nested), and there is no problem with transactional propagation in programmatic transaction management.

Transaction type of EJB:

Nerver: Do not participate in the transaction if participation produces RemoteException
NotSupported: Unable to participate
Supports: If the caller is participating in a transaction, the corresponding EJB call can also participate in the transaction, or you cannot
Mandatory if the caller has a transaction, the corresponding EJB can participate in the transaction, otherwise the Transactionrequiredexception
Required if the caller has a transaction, the corresponding EJB can participate in the transaction, otherwise the container will start a transaction before the corresponding EJB is invoked.
When the method call completes, the transaction is committed.
RequiresNew starts a new transaction before invoking the appropriate EJB, and commits the transaction when the method call returns.

The first six policies are similar to the EJB CMT: constant names are the same, so it should be immediately familiar to EJB developers. The seventh (propagation_nested) is a special variable that spring provides. It requires that the transaction manager either use the JDBC 3.0 savepoint API to provide nested transactional behavior (such as spring's Datasourcetransactionmanager) or support nested transactions through JTA.

The readonly flag in the transaction attribute indicates that the corresponding transaction should be optimized for read-only transactions. This is an optimization hint. In some cases, some transaction policies can have a significant optimization effect, such as avoiding dirty checking (attempting to "refresh") when using the Object/relational mapping tool (such as: Hibernate or TopLink).

In the transaction attribute there is also an option to define a "timeout" value that specifies a transaction timeout of several seconds. In JTA, this is simply passed to the transaction coordinator for the Java server, and is interpreted accordingly.