The @Transactional() annotation has a number of parameters, among which we often use the following:

A, the propagation

Represents transaction propagation behavior. This is how transactions are managed when multiple transaction methods are invoked.

Here the transaction method refers to the database table data change operation method.

For example:

There is an update() method:

public void update() {

}
Copy the code

There is also an add() method:

Public void add() {// update() method is called;Copy the code

So what happens now when one of the methods has the transaction annotation @transactional? Or what about transaction annotations for both?

To solve this problem, There are seven spring transaction propagation behaviors:

  • REQUIRED: The default parameter. If there is a transaction running, the current method runs within that transaction, otherwise it starts a new transaction and runs within its own transaction.
  • REQUIRES_NEW: The current method must start a new transaction and run within its own transaction, and should be suspended if any transactions are in progress.
  • SUPPORTS: If there is a transaction running, the current method runs within that transaction, otherwise it can not run in the transaction.
  • NOT_SUPPORTED: The current method should not be running in a transaction. If one is running, suspend it.
  • MANDATORY: The current method must be running inside a transaction, if no transaction is running, an exception is thrown.
  • NEVER: The current method should not run in a transaction, if there is a running transaction, throw an exception.
  • NESTED: If a transaction is running, the current method should run within that transaction’s NESTED transaction; otherwise, it starts a new transaction and runs within its own transaction.

1. REQUIRED

If there is a transaction running, the current method runs within that transaction, otherwise it starts a new transaction and runs within its own transaction.


@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
  methodB();
  // do something
}
 
@Transactional(propagation = Propagation.REQUIRED)
public void methodB() {
  // do something
}
Copy the code
  • When methodA is invoked, a new transaction is started because there is no transaction in the current context. When methodB is executed, a transaction is found in the current context, so it joins the current transaction to execute.
  • When methodB is invoked separately, a new transaction is started because no transaction exists in the current context.

2. REQUIRES_NEW

The current method must start a new transaction and run within its own transaction, and should be suspended if a transaction is in progress.

@Transactional(propagation = Propagation.REQUIRED) public void methodA() { doSomeThingA(); methodB(); doSomeThingB(); REQUIRES_NEW @transactional (Propagation = propagation.REQUIRES_NEW) public void methodB() REQUIRES_NEW @transactional (propagation = propagation.  { // do something }Copy the code

When methodA is called, transaction A is started. When methodB is executed, transaction B is started, and transaction A is suspended. After transaction B is executed, transaction A continues to execute.

  • Transaction A here is called the outer transaction.
  • Transaction B is called an inner transaction.

3. SUPPORTS

If there is a transaction running, the current method runs within the transaction, otherwise it may not run within the transaction.

@Transactional(propagation = Propagation.REQUIRED) public void methodA() { methodB(); Public void methodB() {// do something} // The transaction attribute is SUPPORTS @transactional (Propagation = propagation.SUPPORTS) public void methodB() {// do something }Copy the code
  • When methodA is invoked, methodB is added to the transaction of methodA and the transaction is executed.
  • When methodB is called separately, the methodB method is executed non-transactionally.

4. NOT_SUPPORTED

The current method should not run in a transaction; if one is running, suspend it.

  • When methodA is called, transaction A is started. When methodB is executed, transaction A is suspended, and methodB is executed in non-transactional mode.
  • When methodB is called separately, the methodB method is executed non-transactionally.

5. MANDATORY

The current method must be running inside a transaction, and if no transaction is running, an exception is thrown.

@Transactional(propagation = Propagation.REQUIRED) public void methodA() { methodB(); Public void methodB() {// do something} public void methodB() {// do something} public void methodB() {// do something something }Copy the code
  • When methodA is invoked, methodB is added to methodA’s transaction and executed transactionally.
  • When methodB is called separately, an exception is thrown because no transaction is currently active.

6. NEVER

The current method should not be run in a transaction; if there is a running transaction, an exception is thrown.

7. NESTED

If a transaction is running, the current method should run within that transaction’s nested transaction; otherwise, it should start a new transaction and run within its own transaction.

  • If methodB is executed separately, transaction B is enabled and executed.
  • When methodA is executed, transaction A is enabled, and inner transaction B is enabled when methodB is executed.

Note that when methodA is executed, this is a nested transaction.

If the outer transaction fails, the operation done by the inner transaction is rolled back. However, the failure of an inner transaction does not cause a rollback of the outer transaction.

Second, the ioslation

Set the transaction isolation level.

Different transaction isolation levels cause different problems, such as dirty reads, non-repeatable reads, and phantom reads.

[Mysql] database transactions, dirty reads, magic reads, non-repeatable reads

To resolve this, you need to set the corresponding isolation level:

  • READ_UNCOMMITTED: read is not committed
  • READ_COMMITTED: Read has been committed
  • REPEATABLE_READ: repeatable read
  • The SERIALIZABLE: serialization

Third, the timeout

Set the timeout period.

The transaction needs to commit within a certain amount of time, and if it is not committed, it is rolled back.

The default value is -1, indicating no timeout. If time is set, the unit is seconds (s).

Four, readOnly

Set read-only or not.

The default value is “false”, which indicates that you can query, add, modify, and delete data.

When set to true, only queries can be performed.

Five, the rollbackFor

Set which exceptions occur before the transaction is rolled back.

Six, noRollbackFor

After setting which exceptions occur, the transaction is not rolled back.