Transactions are atomic operations in which no one part of the operation may succeed unless all parts of the operation succeed. When a successful transaction is committed, any changes it has made to data stores become permanent. Unsuccessful transactions are rolled back so that all data stores are returned to their state prior to the transaction's inception. This transactional approach to data modification helps developers guarantee that data stores maintain a consistent state. This means that there are no surprises . If the account balance database can never have negative values unless the credit database has a corresponding approved record, you must make sure that only legal combinations prevail. If you want to perform a money transfer by deducting funds from one account and crediting another, you need a guarantee that both or neither operations take place. Transactions enable multiple changes such as these to be treated atomically.
Transactions are generally committed through a two-phase process. In the first phase, each of the participants votes to commit or abort the transaction. Although database servers are the most common transaction participants , any transaction-aware software component may participate. If any participant votes to abort the transaction, the transaction is rolled back in the second phase, and the states of all data stores involved are returned to their pretransaction form. If all participants vote to commit, the transaction is committed in the second phase. This does not mean that the operations are completed; it just means that the participants are committed to completing their parts of the transaction sooner or later.
Transactions have several integral facets known as the ACID properties.
The atomicity property refers to the fact that all elements of a transaction are treated as an indivisible unit. A transaction is an all-or-nothing proposition. In a transaction where three database tables are updated, all the tables are updated or none are updated.
The consistency property promises that data stores will remain stable. Manipulation of data will not corrupt or be corrupted by other concurrent operations. Thus, your writes to the database will not collide with those of other objects in the system.
Transactional operations are isolated , or independent, from other users of the data stores involved. Therefore, no other elements of the system ever view a partial transaction. They see the state before or after the transaction only. This means that no object will ever retrieve records from a table reflecting part of another object's transactional updates.
Finally, transactions are durable , indicating that after an operation is committed, it will complete one way or another. A transactional message queue server may need to attempt message delivery for several hours during network outages. Regardless, the message queue server is committed to deliver transaction messages one way or another.