Basic properties of a transaction (ACID) and Propagation properties (propagation)

Introduction to four basic properties of database transactionsAtomicity (atomicity), in which all operations in a transaction are equivalent to an atomic operation, either all succeed or all fail. Consistency (consistency), that is, before and after the transaction execution, for the purpose of the transaction itself, the data in the database is consistent, the database consistency is built on the basis of atomicity, more by the coding programmer to ensure that the most classic case is a, B account transfer between. Isolation (isolation), the isolation of transactions refers to the data visibility between transactions and transactions, which is where this article needs to be described in detail. The database defines a variety of isolation levels to weigh against concurrency and data integrity. Persistence (durability), after the transaction completes, all data is persisted to the database and is not lost for other reasons.

problems with database concurrency:
Dirty Read (Dirty Reads): The so-called dirty reading is the Dirty data (drity) read, and dirty data refers to uncommitted data. That is, a transaction is modifying a record, and before the transaction is completed and committed, the data is in a pending state (which may or may not be rolled back), when the second transaction reads the uncommitted data and further processes it, resulting in uncommitted data dependencies. This phenomenon is called dirty reading. Non-repeatable read (non-repeatable Reads): One transaction reads the same record sequentially, but the data read two times is different, which we call non-repeatable reading. That is, the transaction is changed between two reads and the data is modified by other firms. Phantom Read (Phantom Reads): A transaction re-reads the previously retrieved data in the same query condition, but finds that other transactions have inserted new data that satisfies its query criteria, a phenomenon called Phantom reading.

isolation level of a transaction

The isolation level of the database is mainly divided into four levels, the higher the isolation level, the lower the concurrency, the higher the consistency.

1. Unread (read uncommited)

This is the weakest isolation level of the database (completely non-isolated), there are many problems of dirty reading, non-repeatable reading, and Phantom reading. Examples are as follows:

Since transaction B reads the uncommitted data of the transaction, the data read by transaction B is problematic once it is rolled back.

2. Read submitted (commited)

This level does not allow transaction B to read the updated data for the update operation that transaction A has not yet committed (for the insert operation of transaction A, it is still visible to transaction B before it is committed). Dirty reads are avoided, but non-repeatable reads and phantom reads may occur. Examples are as follows:

There is no dirty read on this side, so that transaction B reads the data after transaction a update commits. However, there is still a case of interaction between transactions (non-repeatable reading), as shown in the following example:

Both transaction A and transaction B read Price first, then subtract a certain value from the price, we expect the result to be 70, but the actual result may be 90 or 80.

3. Repeatable READ (REPEATABLE Read)

None of the data obtained by select can be modified, which prevents the data from being read inconsistent before and after a transaction. However, there is no way to control phantom reading, because other transactions cannot change the selected data at this time, but can increase the data because the previous transaction does not have a range lock.

This isolation level eliminates non-repeatable reads, but because the insert operation transaction b for transaction A is still visible, there is still a phantom-read phenomenon.

4. Serializable read (Serialize)

The highest isolation boundary between transactions, which can only be read sequentially, when a transaction reads and modifies data, another transaction can only be suspended until the transaction that is reading and modifying the data is committed and the pending transaction is executed.

These isolation levels are defined in java.sql. Connection, which we can set when we get the connection, but in general the system is set with the default level of the database.
connection.transaction_read_uncommitted; connection.transaction_read_committed; Connection.transaction_repeatable_read; connection.transaction_serializable;

Summary:

propagation properties of a transaction

When we use spring or EJB declarative programming, we also have access to the transaction's propagation properties (propagation), which are defined in the spring Transactiondefinition class. The following values are specified:
Required (required) Mandatory (mandatory) requiresnew (requires new) Supports (support) notsupported (unsupported) never (not supported)

Required: The current method must require a transaction to be opened, if the current thread does not have a transaction, the new transaction is opened, and if the current thread already has a transaction, it is added to the current transaction. This is often used. However, it is important to note that once a method in the transaction is rolled back, all operations in the current transaction context are rolled back, taking into account the following example:

Assuming that both A and B transactions are required, then when the MethodA is called, if MethodB is rolled back, the change to a is rolled back. So the above code will not achieve the desired result, that is, a cannot be modified to be 99.

Required NEW: The current method must require that the transaction be opened, and if the current thread already has a transaction context, the current transaction is paused, and the previous transaction is resumed until the new transaction has ended. Take the example above, MethodB's changes to the transaction will not affect the MethodA. Two transactions do not affect each other. A common scenario is to send short messages when the business is abnormal. If the business has an exception, the business rolls back, but because the send segment message is a new transaction, it is not affected by the business exception.

Mondary: The current method must require a transaction, and if the current thread does not have a transaction, throws an exception and, if present, joins the transaction.

Support: The current method supports a transaction, and if the current thread has a transaction, it is added to the transaction, and if it does not exist, no action is made.

Not supported: The current method does not support transactions, if the current thread has a transaction, suspends the current transaction, executes the current method, and resumes the transaction. In general, when querying, if a method is only query, and very time-consuming, you can use not support, to avoid the transaction time is very long.

Never: The current method does not support transactions and throws an exception if there is a transaction on the current thread. The use of this is relatively small.