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

Transaction is the so-called business, popular understanding is one thing. From an early age, our parents taught us to do things from the beginning to the end, not to give up halfway. The same is true of affairs. If you don't do it, you can either finish it or don't do it. In other words, affairs must be an indivisible whole, just like the atoms we learned in chemistry, the atoms are the smallest units that make up matter. As a result, people sum up the first characteristic of a transaction: Atomicity. Shit, it's not mysterious at all.

Especially in the database field, transaction is a very important concept, in addition to atomicity, it also has an extremely important feature, that is: Consistency. In other words, after performing the database operation, the data will not be corrupted. For example, if you transfer money from An account to B account, it is impossible to deduct money from An account and not add money to B account. If this kind of thing happens, you will be very angry, what diao bank ah!

When we write a update statement and submit it to the database, it is possible that someone else also submitted a delete statement to the database. Maybe we all operate on the same record, and we can imagine that if we don't control it a little bit, it will be annoying. We must ensure that database operations are "isolated" (and sometimes threads are isolated) without any interference with each other. This is: Isolation.

It is very difficult to really achieve that there is no interference between operations, so database experts who go to work every day begin to use their brains, "We need to develop a specification." let all database vendors support our specification! " The specification is: transaction isolation level (Transaction Isolation Level) It's not easy to define such a powerful specification, but to put it bluntly, there are only four levels:

READ_UNCOMMITTED

READ_COMMITTED

REPEATABLE_READ

SERIALIZABLE

Never translate, it's just a code name. From top to bottom, the level is getting higher and higher, the concurrency is getting worse, and the security is getting higher and higher, and vice versa.

When we execute an insert statement, the database must ensure that a piece of data is permanently stored on disk, which is also a feature of the transaction: Durability.

To sum up, the above mentioned a total of four transaction features, their English word initials together is: ACID, this is the legendary "transaction ACID feature"!

Who is the boss of these four guys?

In fact, it is clear when you think about it: atomicity is the foundation, isolation is the means, persistence is the end, and the real boss is consistency. If the data are inconsistent, it is equivalent to "rivers and lakes are in a mess, and hooligans wear bras." Therefore, these three younger brothers all follow the boss of "consistency" to serve him wholeheartedly.

In fact, the most difficult thing to understand among these four guys is not consistency, but isolation. Because it is an important means to ensure consistency, is a tool, there can be no difference in using it, otherwise you will bear the consequences!

The problems related to reading data caused by transaction concurrency can be described in one sentence:

1. Dirty reading: transaction A reads the uncommitted data of transaction B and does other operations on that basis.

First of all, take a look at "dirty reading". When I see the word "dirty", I think of disgusting and dirty. How can the data be dirty? In fact, it is what we often call "junk data". For example, there are two transactions that are executing concurrently (that is, competing).

The balance should be 1500 yuan! Please take a look at the T5 time point, transaction An at this time the query balance is 0 yuan, this data is dirty data, it is caused by transaction B, obviously the transaction is not isolated, seeping through, messy.

two。 Unrepeatable: transaction A reads the change data that transaction B has committed.

In fact, transaction A didn't do anything except twice. As a result, the money changed from 1000 to 0, which is repeated reading. It is conceivable that someone else did this, not me. In fact, this is also reasonable, after all, transaction B commits the transaction, and the database persists the result, so transaction A reads again and naturally changes.

This phenomenon is basically understandable, but it is not allowed in some abnormal situations. After all, this phenomenon is also caused by the lack of isolation between transactions, but we seem to be able to ignore this problem.

3. Illusion: transaction A reads the new data that transaction B has committed.

Each time the bank staff counted the total deposits, they saw different results. However, this is also quite normal, the total deposit has increased, someone must be saving money at this time. But if the banking system is really designed this way, it's over. This is also caused by the lack of transaction isolation, but for most applications, this also seems normal, understandable, and permissible. Those disgusting systems in the bank are very strict, and when counting, they even isolate all other operations, and this level of isolation is very high.

The first one is resolutely resisted, and the latter two are not considered in most cases.

This is why there must be a transaction isolation level, which is like a wall, isolating different transactions.

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.