In terms of business related knowledge

Preface

Self-reproduced articles for the isolation level and propagation behavior of the transaction in spring
http://blog.csdn.net/gao36951/article/details/38274275, there is about MySQL as an example to explain the database isolation level of http://blog.csdn.net/gao36951/ article/details/38316201 But forget about it over time and confuse the isolation level of the database. Today we thoroughly studied and lifted the puzzle. 1.1 The four characteristics of business cuid

A transaction (Transaction) is a unit of concurrent control and is a user-defined sequence of operations. These operations are either done or not done, and are an indivisible unit of work. With transactions, SQL Server can bind a logically related set of operations together so that the server maintains the integrity of the data.
Transactions are usually started with begin transaction, ending with a commit or rollback.
A commit represents a commit, that is, all operations that commit a transaction. Specifically, all updates to the database in a transaction are written back to the physical database on disk, and the transaction ends normally.
Rollback represents a rollback, that is, a failure occurred while the transaction was running, the transaction could not continue, and the system withdrew all the completed operations in the transaction from the database and rolled back to the state where the transaction began.

Characteristics of transactions (ACID properties)
A: Atomic Sex (atomicity)
A transaction is a logical unit of work for a database, and the operations included in the transaction are either wholly or wholly done.
B: Consistency (consistency)
The result of a transaction execution must be to change the database from one consistency state to another. Consistency is closely related to atomicity.
C: Isolation (Isolation)
Execution of a transaction cannot be interfered by other transactions.
D: Persistence/permanence (durability)
Once a transaction is committed, its changes to the data in the database should be permanent. 1.2 The data isolation level in JDBC

If the DBMS supports transaction processing, it must have some way of managing the conflicts that can occur when two transactions are operating on a single database at the same time. Users can specify transaction isolation levels to indicate how much effort the DBMS should take to resolve potential conflicts. For example, what to do when a transaction changes a value and the second transaction reads the value before the change is committed or restored.

If the first transaction is restored and the change value read by the second firm will be invalid, then this conflict can be allowed. The JDBC user can use the following code to instruct the DBMS to allow reading of the value ("dirty read") before the value is committed, where con is the current connection:
Con.settransactionisolation (transaction_read_uncommitted);

The higher the transaction isolation level, the more effort is spent to avoid conflicts. The connection interface defines level five, where the lowest level specifies that the transaction is not supported at all, and the highest level specifies that any other transaction must not make any changes to the data that the transaction is reading when the transaction is operating on a database. Typically, the higher the isolation level, the slower the application executes (because of the increased resource consumption for locking and fewer concurrent operations between users). When deciding what isolation level to adopt, developers must weigh the performance requirements against the need for data consistency. Of course, the level of actual support depends on the capabilities of the DBMS involved.

When you create a connection object, its transaction isolation level depends on the driver, but is usually the default value of the database involved. Users can change the transaction isolation level by calling the Setisolationlevel method. The new level will take effect for the remainder of the connection process. To change the transaction isolation level for only one transaction, you must set the transaction before it starts and reset it after the transaction ends. We do not advocate making changes to the transaction isolation level in the middle of a transaction, as this will immediately trigger the invocation of the commit method so that any changes made prior to it become permanent.

data isolation level settings for JDBC:

JDBC database Isolation Level data access
transaction_read_uncommitted ur is commonly known as "dirty Read" (Dirty read), can read the updated data when no data is submitted
Transaction_read_committed CS When querying in a transaction allows reading of data before submission, and the current query can read data when the data is submitted. Update data does not lock the table
Transaction_repeatable_read RS does not allow reading data from other transaction updates when querying in one transaction, allowing read of new data submitted by other transactions
Transaction_serializable RR does not allow any data modifications to this query table when it is queried in a transaction. 1.2.1 JDBC Transaction ISOLATION level

    To resolve issues related to "multiple threads requesting the same data," the transactions are separated from each other by a lock. Most mainstream databases support different types of locks; therefore, the JDBC API supports different types of transactions, which are assigned or determined by the Connection object. The following transaction levels can be obtained in the JDBC API:

Transaction_none description does not support transactions.

Transaction_read_uncommitted that a transaction can see a change in another transaction before committing. Such dirty reads, non repeatable read and virtual reads are allowed.

Transaction_read_committed It is not allowed to read uncommitted data. This level still allows non repeatable read and virtual reads to occur.

Transaction_repeatable_read shows that the transaction guarantees that the same data can be read again without fail, but that virtual reads will still occur.

Transaction_serializable is the highest transaction level, preventing dirty reads, non repeatable reads, and virtual reads.

    There are several levels that appear in order to balance performance with consistency. The higher the level of transaction protection, the greater the performance penalty. 
    assuming that your database and JDBC driver support this feature, given a Connection object, you can explicitly set the transaction level you want:
    Conn.settransactionlevel (transaction_ SERIALIZABLE); 
    You can determine the level of the current transaction in the following ways:
        int levels = Conn.gettransactionisolation ();
        if (level = = Connection.transaction_none)
         System.out.println ("Transaction_none");
        else if (level = = connection.transaction_read_uncommitted)
         System.out.println ("transaction_read_uncommitted");
        else if (level = = connection.transaction_read_committed)
         System.out.println ("transaction_read_committed");
        else if (level = = Connection.transaction_repeatable_read)
         System.out.println ("Transaction_repeatable_read");
        else if (level = = connection.transaction_serializable)
         System.out.println ("transaction_serializable");

transaction isolation levels in 1.3 spring

When using AOP to configure transactions, in addition to the default isolation level, the other four are the

Isolation[ˌaɪsəˈleɪʃən] quarantine corresponding to the isolation level in JDBC: The properties support five transaction settings, as described below:
1, Default uses the isolation level set by the database (defaults), which determines the isolation level by the DBA default setting.
2, read_uncommitted will appear dirty read, non-repeatable read, Phantom read (lowest isolation level, high concurrency performance)
3, read_committed will be read-only, the problem of Phantom reading (lock the row being read)
4, Repeatable_ Read will have a phantom read (lock all rows Read)
5, SERIALIZABLE guarantee that all circumstances will not occur (lock the table) 1.4 The propagation characteristics of the transaction propagation propagation_required : If there is a transaction, the current transaction is supported. Open Propagation_supports If no transaction is present: If there is a transaction, the current transaction is supported. If there are no transactions, non-transactional execution propagation_mandatory: If a transaction already exists, the current transaction is supported. If there is no active transaction, an exception is thrown. Propagation_requires_new: Always open a new transaction. If a transaction already exists, the transaction that exists is suspended. Propagation_not_supported: Always executes in a non transactional manner and suspends any existing transactions. Propagation_never: Always executes in a non transactional manner and throws an exception propagation_nested if an active transaction exists: If an active transaction exists, it is run in a nested transaction. If there are no active transactions, then press the Transactiondefinition.propagation_required property to perform the 1.5 default isolation level for mainstream database the isolation level supported in Oracle: Read Committed/serializable, the default is read committed MySQL-supported isolation level: Read Uncommitted/read committed/repeatable read/serializable , the default is repeatable read;

Four concurrent exceptions, four corresponding isolation levels refer to the following blog
http://blog.csdn.net/bluishglc/article/details/5626009
The default isolation level in MySQL and Oracle refers to the following blog post
http://www.it165.net/database/html/201310/4644.html
Spring Transaction Isolation Level reference is the following blog post
http ://www.cnblogs.com/qqzy168/p/3307284.html