Shulou(Shulou.com)06/01 Report--

The four characteristics of transactions (ACID) are Atomicity, Consistency, Isolation, and Durability. Consistency is the purpose of the transaction, atomicity, isolation and persistence are the necessary conditions for consistency.

Isolation: multiple concurrent transactions should be isolated from each other, and there is a sequence in which two concurrent transactions T1 and T2 begin, so that each transaction does not feel that other transactions are executing concurrently.

There are four levels of isolation:

1. Serial Serializable: the strictest level, the transaction is executed serially, and the resource consumption is the largest.

2. Readable REPEATABLE READ: ensures that transaction T1 will not modify the uncommitted data of transaction T2. It avoids the situation of "dirty read" and "non-repeatable read", but brings more performance loss.

3. Read committed READ COMMITTED: it ensures that transaction T1 will not read the uncommitted data of transaction T2 and avoids "dirty reading".

4. Read uncommitted Read Uncommitted: illegal data will be read during reading.

The difference between dirty reading, phantom reading, and unrepeatable reading:

Dirty reading is when T1 reads T2 uncommitted data.

Unrepeatable read is to read the data submitted by the previous transaction. In some cases, non-repeatable reading is not a problem, depending on the result of the final query.

Unrepeatable queries are all for the same data item, while phantom reading is for a batch of data as a whole (such as the number of data).

Four isolation levels and read and write transactions:

Read uncommitted, read will not block any transaction, write will only block write, will lead to dirty read, non-repeatable read, phantom read.

Read has been committed, read will not block any transaction, write block read, write, because write block read, eliminate "dirty read" problem, but read still does not block writing, can not repeat read, phantom read will appear.

Repeatable read, read only block write, write block read and write, read block write avoids the problem of "unrepeatable read", but the read transaction does not block the insert operation to the database, so the "phantom read" problem still exists.

The Serializable database system ensures that the effect of performing such isolation-level transactions is consistent with that of sequential execution.

Default isolation level:

MySQL: can be read repeatedly.

Oracle: only serialization and read submitted levels are supported. Default: read submitted.

Concurrency control:

Add a shared lock to each read row

At this point, we generally adopt the isolation level of READ COMMITTED, and then combine the following concurrency control locking strategies:

* retry the version number of the optimistic Institute

* pessimistic lock for update

* optimistic offline lock

* pessimistic offline lock

Two commonly used attributes of transactions: readonly and timeout, set the transaction timeout to prevent the occurrence of large transactions.

Analysis of transaction model

Flat transaction model: local transaction and JTA transaction.

Several participants involved in transaction management:

1 Resource Manager (Resource Manager): resource manager is generally a database management system.

2 distributed transaction Coordinator (Distributed Transaction Coordinator,DTC): this function is generally implemented by the JavaEE application server we use, such as jboss,websphere,weblogic, etc. This role exists only in JTA transactions.

Transaction manager (Transaction manager): each transaction manager is associated with the corresponding resource manager, which is responsible for committing or rolling back distributed transactions.

4 Application (Application)

The relationship between the above four can be graphically expressed as follows:

In daily system development, we usually use data resources (such as databases) to save the state of the system, so we divide transactions into RESOURCE-LOCAL transactions or JTA global distributed transactions according to the number of data resources involved in the system.

1 RESOURCE-LOCAL transaction

RESOURCE-LOCAL transactions refer to transactions with only one resource management (RM), and transaction operations operate on the same database.

At this point, the role of the transaction coordinator and the transaction manager is realized by the underlying resource manager. For example, at present, when we use Spring to manage transactions, spring does not have transaction function, it just encapsulates the transaction operation of the underlying database.

2 Global transaction or JTA transaction

A standard OTS (Object Transaction Service) for distributed transaction solution is proposed in the world. JavaEE implements OTS, that is, JTS (Java Transaction Service), and java provides the upper layer interface JTA (Java Transaction API) to operate JTS.

A global transaction involves multiple resource managers, so it is necessary to introduce a transaction coordinator (which can be understood as a global transaction manager, which can be based on a reliable message implementation) to adjust.

Communication protocol:

1. The application server communicates with the transaction manager through TX protocol.

2. The transaction manager communicates with the resource manager through XA protocol.

3. Transaction managers communicate with each other through XA+ (XA protocol superset) protocol.

Submission process:

Two-phase commit protocol 2PC (two phase commit)

In the first stage, the transaction coordinator sends a "prepare to commit" message to all transaction managers involved in the transaction, then the transaction manager sends the message to the corresponding resource manager, and then the transaction manager tells the response of the resource management to the distributed transaction coordinator (DTC). Only when this phase is successfully completed (since all resource managers agree to commit the transaction) will the second phase be entered.

Phase 2: when the first phase is successfully completed, the transaction coordinator tells the transaction manager to commit the transaction

Distributed final consistency theory:

CAP theory:

C (consistency) whether the data of multiple nodes are consistent in a distributed environment.

A (availability) service remains available all the time

P (partition tolerance) in distributed applications, the system may not work because of some distributed reasons. Good partition tolerance makes the application a distributed system, but it seems to be a whole that can operate normally.

BASE theory:

BA: Basic Availability basic business availability

S: Soft state flexible statu

E: Eventual consistency final consistency

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.