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

This article will explain in detail how the transaction management of the database is, and the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

In the daily software development, in addition to considering the software performance indicators, we also need to consider the security of the software. When it comes to security, we have to consider transaction management. That is, under the same transaction, the operation on the database is either successfully committed, and as long as there is a failure, the updated data must be rolled back. It is easy to use transactions in spring, because spring not only provides transaction objects independent of underlying transactions, but also provides the function of declarative transactions. The purpose is to decouple the program from the transaction code and facilitate us to add transactions anytime and anywhere.

Before introducing spring transactions, let's take a brief look at the knowledge of database transactions. To put it simply, when multiple SQL statements are executed, either all of them are executed successfully or all fail. Database transactions include four features:

Atomicity: indicates that multiple database operations that make up a transaction are an indivisible atomic unit. The entire transaction is committed only if all operations are executed successfully, and any database operation in the transaction fails. Any operation that has been performed must be rolled back.

Consistency: after a successful transaction operation, the state of the database is consistent with its business rules, that is, the data will not be destroyed. To put it simply, if you transfer money from An account to B account, regardless of whether the operation is successful or not, the total deposits of An and B will not change.

Isolation: in concurrency, different transactions have their own data space, and their operations do not interfere with each other. But this is not absolute, because the isolation levels of many kinds of transactions are specified in the database, and different isolation levels correspond to different degrees of interference. The higher the isolation level, the better the data consistency, but the weaker the concurrency.

Persistence: once the transaction is successfully committed, all data operations in the transaction must be persisted to the database, even if the database crashes, when the database is restarted, it must be able to recover the committed transaction data through some mechanism.

The purpose of the above four features is to ensure the security of the database, so how do you achieve the above features at the bottom of the database?

The way of implementation is similar to that of Java. We know that thread safety is ensured by object locking in Java, so the database is also implemented by locking. It's just that this lock is called a database lock. When multiple transactions attempt to operate on the same data, only the transaction that acquires the database lock can operate on the data, and only when the transaction is committed can the subsequent transaction operate on the data.

In database transactions, if multiple clients access the database at the same time, that is, the data in the database may be accessed by multiple transactions at the same time, if no database isolation measures are taken, it will lead to a variety of concurrency problems, thus destroying the integrity of the data. Let's take a look at what problems will arise in this case:

Dirty reading: a transaction reads the uncommitted change data of transaction B and operates on the basis of this data. At this time, when a rollback operation occurs in transaction B, the data read by transaction An is not up-to-date at all. The most typical problem that occurs in this situation is that dirty reading occurs when withdrawal transactions and transfer transactions are concurrent.

Unrepeatable: if the A transaction reads the data that the B transaction has committed. However, A withdraws another 100 yuan from the account in the process of withdrawal, which will cause A to read the balance of the account for two times.

Phantom reading: the A transaction reads the new data committed by the B transaction, and then the A transaction will have the problem of phantom reading. A common scenario is to assume that the banking system counts the total amount of the deposit account twice in the same transaction, and during the two statistics, a deposit of 100 yuan is added to the account. At this time, the total amount of the two statistics will be inconsistent.

Phantom reading and unrepeatable reading are two different concepts. The former refers to reading the new data of other committed transactions, while the latter refers to reading the changed data or deleted data of committed transactions. The strategies adopted in the two different scenarios are also different. To prevent the changed data from being read, you only need to add a row-level lock to the data of the operation, which can prevent changes in the data in the operation and prevent new data from being read. It is often necessary to add table-level locks, that is, to lock the entire table to prevent new data.

Missing update 1: when the A transaction is undone, the updated data of the committed B transaction is overwritten.

The balance is restored to 1000 yuan (lost update) lost update 2: a transaction overwrites the data that has been committed by B transaction, resulting in the loss of the operation done by B transaction.

About the database transaction management is how to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.