Several major features of the business

Transaction is the so-called business, popular understanding is one thing. From childhood, parents educate us, do things to the beginning and finish, not halfway. The same is true of business, which cannot be done in general, or done or not. In other words, a transaction must be an indivisible whole, like the atoms we learn in chemistry, atoms are the smallest units that make up a substance. Thus, the first characteristic of a transaction is summed up: atomicity (atomicity). I'm not a mystery at all.

Especially in the database domain, the transaction is a very important concept, in addition to atomicity, it has an extremely important feature, that is: consistency (consistency). That is, the data is not destroyed after the database operation has been performed. For example, if you transfer from a account to a B account, it is not possible to deduct money from a account, and B account does not add money. If there is such a thing, you will be very angry, what Diao bank Ah!

When we write an UPDATE statement and commit to the database for an instant, it is possible that someone else has submitted a DELETE statement to the database. Maybe we're all working on the same record, and we can imagine that if we don't get a little bit of control, it's going to be a big problem. We must ensure that database operations are "isolated" (sometimes isolated between threads), without any interference between them. This is: Isolation (isolation).

To really do the operation between the total without any interference is difficult, so, every day to work soy sauce database experts, began to think, "we have to develop a standard, so that the database manufacturers are supporting our specifications!" ", this specification is: Transaction ISOLATION level (Transaction isolation levels). Can define such a good code really is not easy, in fact, plainly on the four levels:

1. read_uncommitted

2. read_committed

3. Repeatable_read

4. SERIALIZABLE

Don't translate, it's just a code name. From the top down, the level is getting higher, the concurrency is getting worse, the security is getting higher and the reverse is reversed.

When we execute an INSERT statement, the database must ensure that a single piece of data is permanently stored on disk, which is also an attribute of the transaction: persistence (Durability).

To sum up, the above mentioned the 4 characteristics of the transaction, the first letter of their English words together is: acid, this is the legendary "Transaction ACID characteristics"!

Who's the boss of these four guys?

In fact, it is clear that the atom is the basis, isolation is the means, persistence is the goal, the real boss is consistency. Data inconsistency, the equivalent of "The lake chaos, rogue wearing a bra." So, these three boys are following the "consistency" this boss mixed, for his wholehearted service.

Of these four guys, the hardest thing to understand is not consistency, but isolation. Because it is an important means of ensuring consistency, is the tool, use it can not have the slightest mistake, or the consequences of self-esteem!

Transaction concurrency caused by the read data related problems, each in a sentence to describe:

1. Dirty read: Transaction a reads the uncommitted data from transaction B, and does other things on that basis.

First look at "dirty reading", see "dirty" the word, I think of nausea, dirty. How can data be dirty? In fact, we often say "junk data". For example, there are two transactions, which are executed concurrently (that is, competition).

The balance should be 1500 yuan! See T5 time, Transaction A at this point the query balance of 0 yuan, this data is dirty data, it is the result of transaction B, the obvious transaction has not been isolated, infiltration over, chaos.

2. Non-repeatable READ: Transaction a reads the change data submitted by transaction B.

Transaction A In fact, in addition to the query two times, nothing else to do, the result of money from 1000 to 0, which is repeated reading. It is conceivable that it was done by others, not by me. In fact, this is also reasonable, after all, transaction B commits the transaction, the database will persist the results, so that transaction A again read nature changed.

This kind of phenomenon is basically understandable, but it is not allowed in some perverted scenes. After all, this phenomenon is also caused by the absence of segregation between transactions, but we seem to be able to ignore this problem.

3. Phantom read: Transaction a reads the new data that transaction B has committed.

Bank staff, each time the total deposit statistics, see the different results. But it is also quite normal, the total deposit has increased, it is certain that someone is saving at this time. But if the banking system is really designed like this, it's done. This is also caused by a lack of isolation of the transaction, but it seems normal, understandable, and permissible for most application systems. Those disgusting systems in the bank, which are very demanding, count, and even isolate all the other operations, even if the isolation level is very high.

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

That's why you have to have a transaction isolation level this thing, it's like a wall, isolating different transactions.

This article is from the "Small Stop" blog, please be sure to keep this source http://10541556.blog.51cto.com/10531556/1828027

Some of the major features of the transaction