ACID, an acronym for the four basic elements of the correct execution of database transactions. Include: Atomicity, Consistency, Isolation, Durability. A database that supports transactions must have these four characteristics. Otherwise, the correctness of the data cannot be guaranteed during the transaction process, and the transaction process may not meet the requirements of the transaction party.
Atomicity
All operations in the entire transaction are either completed or not completed, and it is impossible to stagnate at a certain link in the middle. If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction was never executed.
A transaction can encapsulate state changes (unless it is a read-only). Transactions must always keep the system in a consistent state, no matter how many concurrent transactions are at any given time.
That is to say: if the transaction is concurrent, the system must also operate as a serial transaction. Its main features are Preserving an Invariant. Taking the transfer case as an example, suppose there are five accounts, each with a balance of 100 yuan, then the total amount of the five accounts is 500 yuan. Multiple transfers occur at the same time, no matter how many are concurrent, such as transferring 5 yuan between accounts A and B, transferring 10 yuan between accounts C and D, and transferring 15 yuan between accounts B and E, the total amount of the five accounts It should also be 500 yuan, this is protection and immutability
Transactions are executed in isolation so that they appear to be the only operations the system performs at a given time. If there are two transactions, running at the same time and performing the same function, the isolation of the transaction will ensure that each transaction in the system thinks that only that transaction is using the system. This property is sometimes called serialization. To prevent confusion between transaction operations, requests must be serialized or serialized so that only one request is for the same data at a time.
After the transaction is completed, the changes made by the transaction to the database are persisted in the database and will not be rolled back.
Because an operation usually contains many sub-operations, and these sub-operations may cause problems due to hardware damage or other factors, it is not easy to implement ACID correctly. ACID recommends that the database should operate all the data that needs to be updated and modified at one time, but it is not feasible in practice.
At present, there are two main ways to implement ACID: the first is Write ahead logging, which is a log-style way (modern databases are based on this way). The second is Shadow paging.
Compared with the WAL (write ahead logging) technology, the shadow paging technology is simpler to implement, eliminates the overhead of writing log records, and has a faster recovery speed (redo and undo are not required). The disadvantage of shadow paging is that multiple blocks are output when a transaction is committed, which makes the commit very expensive, and in units of blocks, it is difficult to apply to the case where multiple transactions are allowed to execute concurrently - this is its fatal shortcoming.
The central idea of WAL is that modifications to data files (these are the carriers of tables and indexes) must only occur after those modifications have been logged -- that is, after log records have been flushed to permanent storage. If we follow this process, then we don't need to flush data pages to disk every time a transaction commits, because we know that in the event of a crash, we can use the journal to recover the database: any pages that have not yet been attached to a data page The records will be redone from the log records first (this is called rolling forward recovery, also called REDO) and then the modifications made by those uncommitted transactions will be deleted from the data pages (this is called rolling backward recovery - UNDO).