What is a Transaction?

To illustrate the concept, let us assume that you want to transfer money from a savings account into a current account. In this scenario, it is critical that both the accounts are changed from a successful transaction and neither is affected from an unsuccessful one. You just cannot afford to have your money vaporize if crediting your current account fails for any reason after the debit on your savings account! Therefore, the most important concept that one has to be aware of when dealing with enterprise applications is the concept of a transaction. To a user, a transaction is a single change event that either happens or doesn't happen. Although this may sound like a fairly straightforward and simple requirement, it is hard to make this work in a distributed system without deploying some form of transaction control - computers can fail and messages can be easily lost.
Transactions provide a way to bundle a set of operations into an atomic execution unit. This atomic "all-or-nothing" property is not new; in short, within any transaction, several independent entities must agree before the deal is done. If any party disagrees, the deal is off and the independent entities are reverted back to their original state by invoking a rollover operation.Transactions are essential for distributed applications. Further, transactions provide modular execution, which complements a component technology’s modular programming.

The ACID properties

All transactions subscribe to the following "ACID" properties:
Atomicity - A transaction either commits or rollbacks. If a transaction commits, all of its effects remain. If it rollbacks, then all of its effects are undone. For example, in money transfer example above, the money is deducted from Saving account, and the same amount is added to current account (commit) or nothing changes (rollback).
Consistency - A transaction always leads to a correct transformation of the system state by preserving the state invariance. For example, a transaction adding an element to a doubly linked list, all forward and backward pointers are updated.
Isolation - Concurrent transactions are isolated from the updates of other incomplete transactions. This property is also often called serializability. For example, a second transaction traversing a doubly linked list already undergoing modification by a first transaction will see only completed changes, and be isolated from any non-committed changes of the first transaction.
Durability - If a transaction commits, its effects will be permanent after the transaction commits. In fact, the effects remain even in the face of system failures. It is up to the application to decide what consistency is and to bracket its computation to delimit these consistent transformations. It is the job of the transactional resource managers to provide consistent, isolated and durable transformations of the objects they manage. If the transactions are distributed among multiple computers, the two-phase commit protocol is used to make these transactions atomic and durable.