What is a transaction

▲ Baidu Encyclopedia

In summary, a transaction is a logical unit consisting of a finite set of operations. Transaction operations have two purposes, data consistency and operation isolation. Data consistency means that all operations within a transaction are successfully completed and changes are permanent when a transaction is committed; When a transaction is rolled back, it is guaranteed to return to the state before the transaction was executed. Operational isolation means that multiple simultaneous transactions should be independent of each other.

Both Handsome boy and Xiao Ming have 1000 yuan in their bank accounts. Handsome boy wants to transfer 500 yuan to Xiao Ming.

This process seems simple, but actually involves a series of database operations, which can be simply seen as two basic steps, namely, deducting 500 yuan from the amount of Handsome boy account, and adding 500 yuan to the amount of Xiaoming account.

Assuming that the first step database operation succeeds, the second step fails, then there will be no change in the amount of Xiaoming account, but pretty boy less than 500 yuan, isn’t pretty sad.

The transaction mechanism can avoid this situation to ensure that the entire operation is completed. If one operation fails, all previous database operations will be invalid.

Transaction characteristics

When it comes to transactions, there are inevitably four ACID properties involved:

  • Atomicity: A transaction is executed as a whole, and all or none of the operations on the database contained within it are executed.
  • Consistency: Transactions should ensure that the state of the database changes from one consistent state to another. Consistent state means that the data in the database should meet integrity constraints.
  • Isolation: When multiple transactions are executed concurrently, the execution of one transaction should not affect the execution of other transactions.
  • Durability: Committed transactions that change the database should stay in the database forever.

We refer to transactions that strictly follow ACID properties as rigid transactions. In contrast, the expectation of ultimate consistency, in the intermediate state of transaction execution allows for transactions that temporarily do not follow ACID properties, called flexible transactions. The use of flexible transactions involves distributed transaction schemes, which will be expanded for you later, but will not be explained here.

Spring’s approach to transaction management

1. Programmatic transaction management

Programmatic transaction management is invasive affairs management, can be achieved through the PlatformTransactionManager to transaction management, Spring provides a template class TransactionTemplate for transaction management.

Declarative transaction management

Declarative transaction management is built on AOP, with two common approaches: XML configuration files based on tx and AOP namespaces, and @Transactional annotations, which tend to be used more frequently as Spring and Java get more advanced.

The essence is to intercept before and after the method, then create or join a transaction before the target method starts, commit or roll back the target method as it executes.

Declarative transactions are non-invasive and do not affect the implementation of business logic. You only need to declare relevant transaction rules in the configuration file or through annotations to apply transaction rules to the business logic. And programmatic transaction each implementation should be implemented separately, but when the business volume is large and the function is complex, using programmatic transaction is undoubtedly painful.

Declarative transaction management is clearly preferable to programmatic transaction management, although it is not as flexible as programmatic transaction management, which is the non-intrusive approach to programming that Spring promotes.

By the way, check out the scope of @Transactional:

  1. ** methods: It is recommended that annotations be used on methods, but note that this annotation can only be applied to public methods, otherwise it will not take effect.
  2. ** Class: ** If this annotation is used on a class, it applies to all public methods in that class.
  3. ** Interface: ** This interface is not recommended.

Five attributes of Spring transaction management

1. The isolation level of the transaction

The following problems can occur when multiple transactions are executing simultaneously:

  • ** Dirty reads: ** One transaction reads uncommitted data from another transaction.
  • ** Non-repeatable read: ** A transaction reads the same data successively, but the content of the two reads is inconsistent.
  • ** Phantom read: ** A transaction rreads previously retrieved data with the same query conditions, only to find that another transaction inserts new data that meets its query conditions

The isolation level of a transaction defines the degree of impact of concurrent transaction activity.

  • **ISOLATION_DEFAULT: ** Use the default isolation level of the back-end database (the default isolation level is REPEATABLE_READ for MySQL and READ_COMMITTED for Oracle)

  • ISOLATION_READ_UNCOMMITTED: Allows uncommitted changes to be read. This is the lowest isolation level and is rarely used. Dirty read, phantom read, or unrepeatable read may occur.

  • **ISOLATION_READ_COMMITTED: ** Allows reading from concurrent transactions that have already been committed. Dirty reads are prevented, but phantom and non-repeatable reads may still occur.

  • **ISOLATION_REPEATABLE_READ: ** The result of multiple reads of the same field is consistent unless the data is changed by the current transaction itself. Dirty reads and non-repeatable reads are prevented, but magic reads may still occur.

  • ISOLATION_SERIALIZABLE: The highest isolation level, which is fully compliant with the ACID isolation level. All transactions are executed one at a time so that interference between transactions is completely impossible, that is, this level prevents dirty reads, non-repeatable reads, and phantom reads. But this is also the worst performing of all isolation levels, as it is usually done by fully locking the data tables involved in the current transaction. This level is not usually used.

2. Transaction propagation mechanism

The propagation mechanism of transactions is to solve the problem of how to deal with transactions in the case of nested transactions.

  • PROPAGATION_REQUIRED (default) :

    • If the method executes in a method without a transaction, a new transaction is created.
    • If the execution is in a method that already has a transaction, it is added to the transaction and merged into a single transaction.

  • PROPAGATION_SUPPORTS:

    • If the method is executed in a non-transactional method, it is executed non-transactionally.
    • If the execution is in a method that already has a transaction, it is added to the transaction and merged into a single transaction.

  • PROPAGATION_MANDATORY:

    • If the method executes in a method without transactions, an exception is thrown.
    • If the execution is in a method that already has a transaction, it is added to the transaction and merged into a single transaction.

  • PROPAGATION_REQUIRES_NEW:

    • A new transaction is created whether or not the method is executed in the transaction’s method.
    • However, if the execution is in a method that has a transaction, the transaction in the method is temporarily suspended.
    • The new transaction is committed and rolled back independently of the transaction that called its parent method.

  • PROPAGATION_NOT_SUPPORTED:

    • Whether or not the method is executed in a transactional method, it is executed non-transactionally.
    • However, if the execution is in a method that has a transaction, the transaction is temporarily suspended.

  • PROPAGATION_NEVER:

    • If the method is executed in a non-transactional method, it is also executed non-transactionally.
    • However, if the execution is in a method with a transaction, an exception is thrown.

  • PROPAGATION_NESTED:

    • If the method executes in a method without a transaction, a new transaction is created.
    • If execution is in a method that already has a transaction, create subtransaction execution nested within the current transaction.
    • A nested transaction can be committed or rolled back independently of the encapsulated transaction.
    • The nested transaction is also committed if the external transaction commits, and is rolled back if the external transaction rolls back.

3, read-only

If a transaction contains only queries against the database, you can take advantage of the read-only nature of the transaction and specify the transaction type as readonly. For read-only transactions, the database is optimized.

Some of you may ask, why does the query operation need to add transactions?

Such as doing statistical query or report query such a scenario, may involve multiple queries, multiple query SQL must ensure that the overall read consistency, otherwise, after an SQL query before, after a SQL query, data changes by other users, so the overall statistical query will be read data inconsistent state, at this time, Transaction support should be enabled.

4. Transaction timeout

Transaction timeout refers to the maximum amount of time a transaction is allowed to execute. If the time limit is exceeded but the transaction is not completed, the transaction is automatically rolled back to prevent long-running transactions from unnecessarily consuming database resources.

5. Rollback rules

By default, transactions are only rolled back in the event of runtime exceptions. Errors also cause transactions to be rolled back, but not in the event of checked exceptions.

However, you can declare that a particular checked exception is rolled back as if it were a runtime exception. Similarly, it is possible to declare that a transaction will not be rolled back if a particular exception occurs, even if the particular exception is a runtime exception.

conclusion

The above is the understanding of the Spring affairs, if there is insufficient, also welcome friends to correct.

Stay tuned for scenarios where transactions fail and solutions.

Phase to recommend

The most detailed text parsing Java lock (ultimate)

SpringBoot+Redis implements message subscription publishing

What? Can’t search for resources on GitHub yet? Why don’t you come in?

Be sure to bookmark 5 excellent SpringCloud open source projects

Be sure to collect the front end framework of the 5 back end management systems