|
|
Transactions are all about data being transformed from one state to another. Before giving an accurate definition for transactions, let's look at yet another scenario involving transactions—this time, an example that's not necessarily related to databases. Imagine what happens when a user who is visiting an e-commerce shop decides to buy the items in his or her shopping cart. From the user's perspective, all that's required is a simple action such as clicking the Order Items button. However, the actual processes that happen behind the scenes could be something like the following:
Create a new order in the database by assigning an identifier, storing a customer ID and storing the current date.
Clear the customer's shopping cart.
Charge the customer's credit card.
Send a request to the supplier (or the warehouse) that the ordered items be shipped to the customer.
Update database statistics and perform various other operations depending on the way the e-shop is designed to work.
Finally, send the customer a confirmation e-mail containing details about his or her order.
Of course, this list of individual tasks is purely hypothetical, but it gives you an idea about the work that needs to be done after the customer clicks a single button. This is another example of a complex operation that's composed of many smaller ones.
You need to be sure that the specified operations execute either in their entirety or not at all. The process outcome should be black or white, success or failure, nothing in between.
So, in more formal terms, a transaction is a logical unit of work consisting of a sequence of separate operations that brings a system from one consistent state to another. The data should be, at any moment, in a consistent state. The transaction is successful if all of its constituent operations are successful. If any of the operations fail (because of any kind of software or hardware problem), all the changes made by the successful operations are reversed, and the system is brought back to its original state. A transaction can either succeed or fail, but nothing in between. In both cases, the system is brought to a consistent state.
If a problem occurs, all the successful operations are reversed, and everything goes back to the way it was before starting the transaction. This process of reversing the successful operations is called a transaction rollback.
If, instead, everything goes just fine and all operations complete successfully, the changes are declared to be permanent, and you say that the transaction has been committed. After a transaction is committed, it can't be rolled back.
Transactions (not only the database ones) must conform to a set of properties, collectively known as the ACID properties.
ACID is an acronym used to describe the four properties of a transaction:
Atomicity refers to the all-or-nothing nature of a transaction: The transaction executes completely, or it doesn't execute at all. In the case of a failed transaction, all the successful individual actions need to be reverted, and the transaction is rolled back to the original state. Atomicity is perhaps the most representative property of transactions and it's typically used when describing and defining transactions. Nevertheless, the other three properties are just as important as this one.
Consistency refers to the fact that a transaction must take the system from one consistent state to another consistent state. That is, the transaction as a whole must not break any business rules specified for the environment. Contrary to the atomicity property, consistency isn't a rule that the database system can take care of: You, the programmer, must make sure the system gets to a consistent state (in respect to the rules that you define) after the transaction successfully completes.
Isolation specifies that each transaction should perform independently of the other transactions and operations that happen at the same time. In practice, this means that the outside world shouldn't see individual changes to the database while the transaction is happening. In other words, changes made by the active transaction aren't visible to other concurrently running transactions—this is essential, especially because you can't know ahead of time if the transaction will be successful. The changes made by a transaction are declared permanent and become visible to the other transactions and processes only after the transaction is committed.
Durability ensures that after the transaction is completed, its outcome is persisted and resists even in the event of a system failure. So, after a transaction is committed, you can be sure its results are persisted even if the power goes down one second later.
|
|