Introduction
You've probably heard about transactions in real life. Perhaps this word reminds you of buying or selling something, or you may think about a bank transaction with money moving in and out of someone's bank account. Generally, a transaction is a minimal logically meaningful operation that can only be performed completely.
Among all transactions, there is one special type called database transaction.
Database transactions symbolize a unit of work performed within a DBMS (database management system) against a database. A transaction generally represents any change in a database, which can include retrieval, insertion, deletion, or modification.
In this topic, we will discuss in detail what database transactions are and why they are so important.
Concept of transactions
To illustrate the concept of transactions, we will focus on a simple payment system.
Imagine you are buying coffee with a credit card. This activity can be divided into two sequential operations:
1. the price of a cup of coffee is subtracted from the customer's bank account.
2. the price of a cup of coffee is added to the bank account of the coffee shop.
Any of these operations can fail due to software or hardware malfunction, and the payment system should handle that:
if operation (1) fails, operation (2) should be aborted.
if operation (1) succeeds and operation (2) fails, operation (1) should be rolled back (the subtracted amount of money should be returned to the customer).
In other words, the payment system should ensure that either both operations (1) and (2) succeed and the changes are committed (made permanent against a database) or, in case of any failure, all the applied changes should be rolled back. In general, one transaction is executed as shown below:
As we can see, there are two different possible outcomes of our simple buying coffee example:
1. if both operations are successful, then we use the "COMMIT" command saving the changes.
2. if, on the other hand, any operation encounters some errors, then we use the "ROLLBACK" command and return our database to the previous consistent state.
So, in general, a transaction is a single unit of work. If a transaction is successful, all of the data modifications made during the transaction are committed and become a permanent part of the database. If a transaction encounters some errors and must be canceled or rolled back, then all of the data modifications are erased.
Now you get the idea: the main principle of a transaction is all or none.
Properties of transactions
A transaction is characterized by four properties, often referred to as the ACID properties: atomicity, consistency, isolation, and durability.
Atomicity requires that each transaction is "all or nothing". If one part of a transaction fails, the entire transaction fails. This property is ensured by the transaction recovery subsystem of a DBMS.
Consistency ensures that any transaction will take the database from one valid state to another and there would be no middle-states.
Isolation means that every transaction has a well-defined boundary; that is, it is isolated from another transaction. One transaction shouldn't affect other transactions that are active at the same time.
Durability means that data modifications that occur within a successful transaction are kept permanently within the system regardless of what else occurs.
States of transactions
During its life cycle, any transaction passes through several different states. These state changes occur due to modifications, insertions, and deletions (all together called updates). For the sake of simplicity, let's take a look at the 5 most common and typical transaction states.
state | description |
|---|---|
active | A transaction enters into an active state when execution of a transaction begins. In this state, read/write operations can be performed. |
partially committed | In this state, some of the operations have been successful, but there are no permanent changes made against the database. |
failed state | If at least one of the operations encountered errors, or failure occurs in making a permanent change of the data against the database, the operations go into "Failed state". |
aborted | After having encountered any type of error, the transaction goes from "Failed state" to "Aborted state": the changes are deleted or rolled back to the database's previous consistent state. |
committed | All of the operations were successfully executed and the changes were made permanent against the database. |
Note that it's really important to keep transactions pending for the shortest period of time. Otherwise, this can seriously degrade their performance. Please note, that when you use transactions, you put locks on the data that are pending for permanent change to the database. No other operations can take place on locked data. This is called concurrency, which means that the database handles multiple updates at one time. So, as you can see, transactions make DBMS recoverable. In other words, they make it tolerant to system failures and able to provide services even if such failures occur because the database only moves from one consistent state to another, and between these consistent states, no permanent changes are made against the database.
Conclusion
Transactions group a set of tasks into one unit of work, which is then executed. If one of the tasks fails, then the whole transaction fails. Only when all of the tasks are successfully executed, the transaction is successful as well. This helps preserve the integrity and credibility of databases.
Congratulations! Now you've gained some understanding of the transactions. Let's practice, shall we?