How to deeply analyze transactions in JavaWeb

How to deeply analyze JavaWeb transactions, I believe that many inexperienced people are helpless about this, this article summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

The transaction, which everyone is familiar with, basically goes to Spring transaction. In fact, Spring transaction management is based on the transaction processing mechanism of the underlying database itself. The foundation of database transactions is the foundation for mastering Spring transaction management. The following summarizes database transactions.

I. Database services

Its idea: we are lumbering tired. Multiple SQL statements (a team), all of which either succeed or fail.

Its ultimate goal: data will not be corrupted. That is, the transaction operation is successful, and the result of the data is consistent with the expected result of the business. This is consistency in ACID. What is ACID?

II. ACID

The above is the idea, and the cow immediately models according to the idea that database transactions in DBMS satisfy 4 characteristics, namely atomicity, consistency, isolation and persistence. Below is a vivid explanation:

a) Atomicity

An atom is the smallest unit of matter, i.e. it cannot be divided into any more.

For example, in MySQL, every simple SQL statement is contained in a transaction and atomic. Someone asked, how many SQL?

BEGIN TRANSACTION; INSERT INTO `test`.` city` (`state`, `country`, `name`) VALUES ('1 ', ' China','CHINA',' error statement has more VALUE'); INSERT INTO `test`.` city` (`state`, `country`, `name`) VALUES ('1', 'China', 'CHINA'); COMMIT;

Result: Implementation failed. Lines 3-5: SQL for an error. Lines 6-8: Is a correct SQL. They are each wrapped in their own implicit transaction, Read Uncommitted. T-all wraps around the atomicity of T-1 and T-2 above, realizing larger atoms, as shown below.

b) Consistency

*** Goal: Data will not be corrupted. (Isn't that nonsense? Specifically, after the transaction operation is successful, the state of the database is consistent with its business rules, that is, the data will not be destroyed. For example, two UPDATE statements, transfer from account A to account B, regardless of success or failure, the total amount of accounts A and B is the same.

c) Isolation

Isolation: means no interference. There is no interference between transactions, that is, each transaction is independent and does not intersect. This allows multiple threads to access the database concurrently. As shown in the figure:

But smart friends know that if transactions are completely isolated, allowing only one transaction to access the database at a time, the rest are blocking. It'll be very slow.

But smart friends also know that this will cause data concurrency problems. (Yes, see section III below).

d) Persistence

The data must be persisted to a database (stored on disk). Committed transactions, even if the database crashes after committing, can be re-executed on unpersisted data according to the log when restarting the database. (Ask yourself, what about the undelivered items? That's tragic."