Database transactions are a series of operations performed as a single logical unit of work.
Imagine a transaction for online shopping. the payment process includes at least the following database operations:
· Update the inventory information of the products purchased by the customer
· Save customer payment information-may include interaction with the banking system
· Generate an order and save it to the database
· Update user information, such as the number of shopping items
Under normal circumstances, these operations will go smoothly, the transaction will be successful, and all database information related to the transaction will be updated. However, if an error occurs in any part of the process, for example, an exception occurs when updating the inventory information, or the customer's bank account has insufficient deposits, the transaction will fail. Once a transaction fails, all the information in the database must remain unchanged before the transaction. For example, if the last step fails to update the user information, the transaction fails, make sure that the failed transaction does not affect the database status-the inventory information is not updated, the user has not paid, and the order has not been generated. Otherwise, the database information will be messy and unpredictable.
Database transactions are a technology used to ensure the stability and predictability of transactions in such circumstances.
ACID properties of database transactions
Transaction Processing ensures that data-oriented resources are not updated permanently unless all operations in the transaction unit are successfully completed. By combining a group of related operations into a unit that either succeeds or fails, you can simplify error recovery and make the applicationProgramMore reliable. To become a transaction, a logical unit of work must meet the so-called acid (atomicity, consistency, isolation, and durability) attributes:
· Atomicity
A transaction must be an atomic unit of work. modifications to its data must either be performed in all or not. Generally, operations associated with a transaction share a common goal and are mutually dependent. If the system executes only one subset of these operations, the overall goal of the transaction may be broken. Atomicity eliminates the possibility of a subset of system processing operations.
· Consistency
When the transaction is completed, all data must be consistent. In related databases, all rules must be applied to transaction modifications to maintain the integrity of all data. At the end of the transaction, all internal data structures (such as B-tree indexes or two-way linked lists) must be correct. Some maintenance consistency responsibilities are borne by application developers who must ensure that the application has enforced all known integrity constraints. For example, when developing an application for transfer, do not move any decimal point during transfer.
· Isolation
Modifications made by a concurrent firm must be isolated from those made by any other concurrent firm. The status of the data when the transaction is viewing the data is either the status before the transaction is modified or the status after the transaction is modified. The transaction does not view the data in the intermediate status. This is called serializability because it can reload the starting data and replays a series of transactions so that the State at the end of the data is the same as that of the original transaction execution. When a transaction is serializable, the highest isolation level is obtained. At this level, the results obtained from a group of parallel transactions are the same as those obtained by running each firm consecutively. Since high isolation limits the number of transactions that can be executed in parallel, some applications reduce the isolation level in exchange for greater throughput.
· Persistence
After the transaction is completed, its impact on the system is permanent. This modification will remain even if a fatal system failure occurs.