Transaction attributes, transaction isolation levels, problems that may occur with concurrent transactions, spring transaction database locks

1.0 Transaction Characteristics (ACID)

Atomicity: Atomicity, a transaction cannot be split

Consistency: Consistency, the data in the database is in the correct state before the transaction executes, and the data of the database is in the correct state after the transaction execution is complete, that is, the data integrity constraint is not destroyed; For example, we do the bank transfer of the related business, a transfer to B, a transfer of money B must be received. If a turns money and B does not receive, then the database data consistency is not guaranteed, in doing high concurrency business should pay attention to reasonable design.

Isolation: Isolation, no impact between concurrent transaction execution, operations within one transaction have no effect on other transactions, which requires a transaction isolation level to specify isolation;

Durability: Persistence, once a transaction succeeds, its data changes to the database must be permanent and will not cause data inconsistency or loss due to various exceptions.

1.1 Isolation levels for transactions

Read_uncommitted dirty reads, non-repeatable reads, Phantom reads (lowest isolation level, high concurrency)

Read_committed will appear non-repeatable read, Phantom read problem (lock the row being read)
Repeatable_read will read (lock all rows Read)

SERIALIZABLE ensure that all conditions do not occur (lock table)

The default isolation level for most databases is: Read commited, such as SQL Server, Oracle. The default isolation level for a few databases is repeatable Read, such as the MySQL InnoDB storage engine

1.2 Issues caused by transaction concurrency

1.2.1 Dirty Read : Data modified transaction not committed, another transaction read to uncommitted data! (The transaction did not submit another transaction to the uncommitted data)

1.2.2 Non-repeatable read : The same transaction two read data is not the same; the first transaction reads the data, the second transaction modifies the data commit, and the first transaction reads the data again, so that the data read by the first transaction two times is inconsistent.

1.2.3 : Two transactions, the first transaction modifies the data for all rows, the second transaction inserts a data submission, and the 1th transaction commits a data that is not modified.

1.2.4 First class loss (rollback lost):

When 2 transactions update the same data source, if the first transaction is committed and the other transaction is revoked, then the same as the new one is revoked. Which means that the first transaction was lost with the new one.

1.2.5 Second Class update lost (overwrite lost)

Deepen your understanding:

1. The difference between non-repeatable reading and Phantom reading

Both are the same transaction two reads inconsistent, one is the other transaction modified read inconsistent, one is the other transaction insert/delete read inconsistent.

2.spring transactions

Cited article: http://blog.csdn.net/it_man/article/details/5074371

2.1 Transaction propagation behavior (Transaction propagation Behavior)

Transactions propagate in methods.

1. Propagation_required
2. Rropagation_requires_new
3. propagation_nested
4. Propagation_supports
5. propagation_not_supported
6. Propagation_never
7. Propagation_mandatory

The first thing to be clear is, where does the transaction come from? Spread to where? The answer is to propagate from method A to method B. Spring solves only the transactional propagation between methods, and that's a lot of things, like:

1. Method A has a transaction, and method B has a transaction.
2. Method A has a transaction, and method B does not have a transaction.
3. Method A does not have a transaction, and method B has a transaction.
4. Method A does not have a transaction, and method B does not have a transaction.

Assuming that the transaction is propagated from method A to method B, you need to face method B and ask yourself a question:

Does method A have a transaction?

1. If not, create a new transaction and, if so, join the current transaction. This is propagation_required, which is also the default transaction propagation behavior provided by Spring, and is suitable for most situations.
2. If not, a new transaction is created and, if so, the current transaction is suspended. This is rropagation_requires_new, which means creating a new transaction that has nothing to do with the original transaction.
3. If not, create a new transaction and, if there is one, nest other transactions in the current transaction. This is propagation_nested, the legendary "nested transaction", where the nested child transactions are associated with the primary transaction (when the primary transaction commits or rolls back, the child transaction is committed or rolled back).
4. If not, it is executed in a non-transactional manner, and if so, the current transaction is used. This is propagation_supports, this way very casual, there is no, there is, a little indifferent attitude, anyway I am supportive of you.
5. If not, it is executed in a non-transactional manner, and if so, suspends the current transaction. This is propagation_not_supported, this way very tough, no no, there is I do not support you, hang you up, do not bird you.
6. If not, it is executed in a non-transactional manner, and if so, throws an exception. This is propagation_never, this way is more fierce, there is no, there is an error, indeed enough cow, it said: I never support business!
7. If not, an exception is thrown, and if so, the current transaction is used. This is propagation_mandatory, this way can be said to be a big bang, no business directly on the error, indeed enough ruthless, it said: I must have business!

2.2 Spring Transaction ISOLATION LEVEL

Default uses the isolation level set by the database, which defaults to the DBA setting to determine the isolation level.

Read_uncommitted dirty reads, non-repeatable reads, Phantom reads (lowest isolation level, high concurrency)

Read_committed will appear non-repeatable read, Phantom read problem (lock the row being read)
Repeatable_read will read (lock all rows Read)

SERIALIZABLE ensure that all conditions do not occur (lock table)

The key to non-repeatable reading is to modify:
The same condition that you read the data, read it again and find that the value is different
The focus of Phantom reading is to add or delete
The same conditions, the 1th and 2nd readings of the number of records are not the same

1, Serializable: The strictest level, the transaction serial execution, the resource consumes the most; 2. Repeatable READ: Ensures that a transaction does not modify data that has been read by another transaction but not committed (rolled back). "Dirty reads" and "non-repeatable reads" are avoided, but more performance losses are incurred. 3. Read COMMITTED: The default transaction level for most mainstream databases ensures that one transaction does not read to another data that has been modified but not committed by a parallel transaction, avoiding "dirty reads". This level applies to most systems. 4, READ UNCOMMITTED: Ensure that the read process will not read illegal data. The isolation level is a concurrency problem that handles multiple transactions.

2.3 How spring transactions are managed

Declarative transactions: Transactionproxyfactorybean configured in a spring configuration file or using annotations

Programmatic transactions: Transactiontemplate Platformtransactionmanager

3. Database lock

1. Pessimistic Lock: Use the lock mechanism of the database itself to implement. Through the understanding of database lock, it is possible to use transaction isolation level in accordance with the specific business situation and to reduce the concurrency wait by manually specifying the locking method such as reducing the granularity of the lock.
2. Optimistic Lock: Use the program to handle concurrency. Principles are relatively good understanding, the basic one can understand. There are about 3 ways of doing this
   1. Adds a version number to the record.
   2. Timestamp the record.
   3. Pre-read and contrast the data that will be updated.

Whether it is the lock mechanism of the database system itself or the lock mechanism on the business data level of optimistic locking, it is essentially the reading, writing and judging of the state bits.

Http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html

Reference article:

http://www.codeweblog.com/%E4%BA%8B%E5%8A%A1-%E9%94%81-spring%E6%94%AF%E6%8C%81/

http://blog.csdn.net/it_man/article/details/5074371

Http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html

Http://www.cnblogs.com/yldIndex/p/spring_Transactional.html

http://blog.csdn.net/yangchangyong0/article/details/51996708

Transaction attributes, transaction isolation levels, problems that may occur with concurrent transactions, spring transaction database locks