1. What is a transaction?
Transaction: It is the smallest unit of work for database operations. It is a series of operations executed as a single logic; these operations are submitted to the system as a whole, either all are executed or none are executed; a transaction is a set of indivisible operations.
Transactions are the basic unit of recovery and concurrency control.
Transactions have four characteristics: atomicity, consistency, isolation, and durability. These four characteristics are often called ACID.
2. Characteristics of transactions (ACID)
Atomicity: All operations in a transaction are either completely completed or not completed, and will not end at any intermediate stage. If an error occurs during the execution of the transaction, it will be rolled back to the state before the transaction started, as if the transaction had never been executed. That is, transactions are indivisible and irreducible.
Consistency: The integrity of the database is not compromised before the transaction begins and after the transaction ends. This means that the data written must fully comply with all preset constraints, triggers, cascading rollbacks, etc.
Isolation: The database's ability to allow multiple concurrent transactions to read, write and modify its data at the same time. Isolation can prevent data inconsistency due to cross execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including uncommitted read (Read uncommitted), committed read (read committed), repeatable read (repeatable read) and serializable (Serializable).
Durability: After the transaction is completed, the modifications to the data are permanent and will not be lost even if the system fails.
3. Transaction isolation level
There are four isolation levels for database transactions, from low to high: Read uncommitted, Read committed, and Repeatable read.Serializable. Moreover, dirty reads, non-repeatable reads, phantom reads, and transaction losses may occur during concurrent transactions.
Dirty read: (a new uncommitted transaction was read and then rolled back)
Transaction A read uncommitted data in transaction B. If transaction B rolls back, A's read uses the wrong data.
Non-repeatable read: (Reading the submitted new transaction refers to the update operation)
Non-repeatable read means that for certain data in the database, multiple queries within a transaction range return different data values. This is due to the Query interval, modified and committed by another transaction.
Phantom read: (It also reads the new transaction submitted, which refers to the additional operation)
In the composition of multiple reads of transaction A, transaction B performed new operations on the data, resulting in inconsistency in the data read multiple times by transaction A.
The first type of thing loss: (called rollback loss)
For the first type of thing loss, for example, A and B are executing a piece of data at the same time, and then thing B has been submitted, and then thing A is rolled back, so the operation of thing B is lost due to the rollback of thing A, and the second type of thing is lost
. Loss: (Submission coverage loss )
For the second type of thing loss, also called coverage loss, that is, A and 8 execute a data together, and both get a data at the same time, and then B thing is submitted first, but A thing is added and then submitted. , thus covering thing B
Read uncommitted
, as the name suggests, means that one transaction can read the data of another uncommitted transaction. Dirty reads will occur.
Read committed
, as the name suggests, means that a transaction must wait for another transaction to commit before it can read data. Non-repeatable reads will occur.
Repeatable read
means that when starting to read data (transaction is started), modification operations are no longer allowed. Phantom reading may occur.
Serializable
Serlalizable is the highest transaction isolation level. At this level, transactions are executed serially and sequentially, which can avoid dirty reads, non-repeatable reads, and phantom reads. However, this transaction isolation level is inefficient and consumes database performance, so it is generally not used.
The default transaction isolation level of most databases is Read committed, such as SQL Server and Oracle. The
default isolation level of Mysal is Repeatable read
4. Transaction propagation behavior (in order to solve the transaction problem of calling each other between business layer methods):
When a transaction method is called by another transaction method, you must specify how the transaction should be propagated. For example: the method may continue to run in the existing transaction, or it may start a new transaction and run in its own transaction. The TransactionDefinition definition includes the following constants that represent propagation behavior:
1. PROPAGATION_REQUIRED: Default transaction type; if not, create a new transaction; if there is, add the current transaction. Suitable for most situations.
2. PROPAGATION_REQUIRES_NEW: If there is no transaction, create a new transaction; if there is one, suspend the current transaction.
3. PROPAGATION_NESTED: If not, create a new transaction; if there is, nest other transactions in the current transaction.
4. PROPAGATION SUPPORTS: If not, execute in non-transactional mode: If yes, use the current transaction
5. PROPAGATION NOT SUPPORTED: If not, execute in non-transactional mode. If yes, suspend the current transaction. That is, transactions are not supported anyway.
6. PROPAGATION_NEVER: If not, execute in a non-transactional manner. If so, throw an exception.
7. PROPAGATION MANDATORY: If not, throw an exception. If so, use the current transaction.
Summarize:
[1] life and death without any affairs
PROPAGATION NEVER: If not, the transaction will not be executed, and if there is, an exception will be thrown.
PROPAGATION_NOT_SUPPORTED: If not, it will be non-transaction execution. If it is, it will be suspended directly, and then it will be non-transaction execution.
[2] Dispensable
PROPAGATION SUPPORTS: Use it if you have it, forget it if you don’t have it
[3] Must have affairs
PROPAGATION_REQUIRES_NEW: Create a new transaction whether there is one. If there is one, suspend the original one. PROPAGATION_NESTED: If there is no one, create a new transaction. If there is one, nest other transactions in the current transaction. PROPAGATION REQUIRED: If there is no one, just create a new transaction. ;If there is, join the current transaction PROPAGATION MANDATORY: If there is not, throw an exception, if there is, use the current transaction.
What needs to be pointed out here is that the previous six transaction propagation behaviors were introduced by Spring from EJB, and they share the same concept. And PROPAGATION_NESTED is unique to Spring. The transaction started with PROPAGATION_NESTED is embedded in the external transaction (if there is an external transaction). At this time, the embedded transaction is not an independent transaction. It depends on the existence of the external transaction. Only through the submission of the external transaction can the internal transaction be caused. Submission of transactions, nested sub-transactions cannot be submitted separately. If you are familiar with the concept of SavePoint in JDBC, nested transactions are easy to understand. In fact, nested sub-transactions are an application of save points. A transaction can include multiple save points. Each nested transaction subtransaction. In addition, the rollback of external transactions will also cause the rollback of nested sub-transactions.