Spring Transaction Propagation

Seven transaction propagation behaviors are defined in the Transactiondefinition interface.

Propagation_required If there is a transaction, the current transaction is supported. If there is no transaction, a new transaction is opened. Default behavior

Propagation_supports If there is a transaction, the current transaction is supported. If there are no transactions, the execution of the transaction is not performed. However, the transaction manager for transactional synchronization, Propagation_supports is slightly different from the unused transaction.

Propagation_mandatory if a transaction already exists, the current transaction is supported. If there is no active transaction, an exception is thrown.

Propagation_requires_new always opens a new transaction. If a transaction already exists, the transaction that exists is suspended.

Propagation_not_supported always executes in a non transactional manner and suspends any existing transactions.

Propagation_never is always executed in a non transactional manner and throws an exception if there is an active transaction

propagation_nested If an active transaction exists, it is run in a nested transaction. If there are no active transactions, press the Transactiondefinition.propagation_required property to perform

This article mainly explains propagation_required,propagation_requires_new, propagation_nested

in practical applications, the SERVICEA call ServiceB is often present. In that case, ServiceA and SERVICEB between the business is how to pass it.

Example 1:

/** Transaction default is required*/
@Transactional
@Service ("UserService")
public class Userserviceimpl implements Userservive {
@Autowired
Private Usermapper Userdao;

@Autowired
Private Commonservice Commonservice;


Public list<userinfo> getusers () {

return Userdao.selectusers ();
}

@Transactional (propagation = propagation.required)
public void Updateuseragebyid (int age, long id) {

Userdao.updateuserinfobyid (age, ID);

Commonservice.updateuserextbyid ("Unknown", 1);

int b = 1/0;

/* Try {
Commonservice.updateuserextbyid ("Unknown", 1);
catch (Exception e) {
Todo:handle exception
}*/
}
}

//@Transactional
@Service ("Commonservice")
public class Commonserviceimpl implements Commonservice {

@Autowired
Private Usermapper Userdao;

If a Run-time exception occurs, the exception is rolled back and thrown externally
@Transactional (propagation = propagation.nested)
public void Updateuserextbyid (String address, long ID) {

Userdao.updateuserextbyid (address, id);

int a = 1/0;
}
}

The Updateuseragebyid transaction in this example UserService is declared as propagation.required, and the Updateuserextbyid method in Commonservice is invoked. And this method transaction is declared as propagation.nested. As explained above, Commonservice will run in nested transactions. After testing, when Updateuserextbyid

When an exception occurs, the self rolls back and rolls back to the savepoint before it executes. and throws an exception out, UserService can choose whether to rollback or not rollback if the exception is captured. If no processing is done, the same data can occur rollback.

Example 2:

@Transactional (propagation = propagation.required)
public void Updateuseragebyid (int age, long id) {

Userdao.updateuserinfobyid (age, ID);

Commonservice.updateuserextbyid ("Unknown", 1);

int b = 1/0;

If a Run-time exception occurs, the exception is rolled back and thrown externally
@Transactional (propagation = propagation.nested)
public void Updateuserextbyid (String address, long ID) {

Userdao.updateuserextbyid (address, id);

int a = 1/0;
}

The exception occurs in the UserService method because it belongs to a nested transaction, so both UserService and Commonservice are rolled back.

Example 3:

@Transactional (propagation = propagation.required)
public void Updateuseragebyid (int age, long id) {

Userdao.updateuserinfobyid (age, ID);

Commonservice.updateuserextbyid ("Unknown", 1);

int b = 1/0;

//If a Run-time exception occurs, it rolls back and throws an exception outside
@Transactional (propagation = propagation.requires_new)
public void Updateuserextbyid (String address, long ID) {

Userdao.updateuserextbyid (address, id);

int a = 1/0;
}

The simulation here is that Commonservice uses propagation.requires_new. Transactions in the UserService are suspended. Commonservice will open a new business. After testing, the Commonservice exception is simulated here, and its corresponding transaction is rolled back. Also here will throw an exception, userservice as the case for exception handling, select Rollback or not rollback.

Example 4:

@Transactional (propagation = propagation.required)
public void Updateuseragebyid (int age, long id) {

Userdao.updateuserinfobyid (age, ID);

Commonservice.updateuserextbyid ("Unknown", 1);

int b = 1/0;

If a Run-time exception occurs, the exception is rolled back and thrown externally
@Transactional (propagation = propagation.requires_new)
public void Updateuserextbyid (String address, long ID) {

Userdao.updateuserextbyid (address, id);

int a = 1/0;
An exception has been simulated here for UserService. Let's guess if commonservice will roll back. The result of the test is that Commonservice will not roll back. Because before an exception occurs in UserService. Commonservice's business has been commit.

Example 5:

@Transactional (propagation = propagation.required)
public void Updateuseragebyid (int age, long id) {

Userdao.updateuserinfobyid (age, ID);

Commonservice.updateuserextbyid ("Unknown", 1);

int b = 1/0;

try {
Commonservice.updateuserextbyid ("Unknown", 1);
catch (Exception e) {
Todo:handle exception
}
}

@Transactional (propagation = propagation.required)
public void Updateuserextbyid (String address, long ID) {

Userdao.updateuserextbyid (address, id);

int a = 1/0;
}

Finally, let's take a look at the same propagation.required. This simulates commonservice exceptions without suspecting that Commonservice will certainly roll back. But here UserService has an exception capture, UserService will be rolled back. The answer is no. Because Commonservice does not throw an exception at all. Both use a transaction, Commonservice an exception, and the entire transaction is rollback directly.

Well, it's probably clear the propagation relationship of spring transactions. There are many communication relationships on the Internet, but they are all foggy. So here is the article to record.