A transaction comprises a unit of work performed within a database management system against a database, and treated in a coherent and reliable way independent of other transactions.

Transactions in a database environment have two main purposes. 1. To provide reliable units of work that allow correct recovery from failures and keep a database consistent even in cases of system failure, when execution stops and many operations upon a database remain uncompleted, with unclear status. 2. To provide isolation between programs accessing a database concurrently. If this isolation is not provided the programs outcome are possibly erroneous.

A database transaction must be atomic, consistent, isolated and durable.

Atomicity requires that database modifications must follow an "all or nothing" rule. Each transaction is said to be atomic. If one part of the transaction fails, the entire transaction fails and the database state is left unchanged.

The consistency property ensures that any transaction the database performs will take it from one consistent state to another, which states that only consistent data will be written to the database.

Isolation refers to the requirement that no transaction should be able to interfere with another transaction at all. In other words, it should not be possible that two transactions affect the same rows run concurrently, as the outcome would be unpredicted and the system thus made unreliable.

Durability means that once a transaction has been committed, it will remain so.In other words, every committed transaction is protected against powerloss/crash/errors and cannot be lost by the system and can thus be guaranteed to be completed.

A transaction may be in one of the following states:

Aborted--The transaction has aborted. All participants have been notified or are currently inaccessible. After a transaction has aborted, it is immediately removed from the list of transactions. It is not possible to change the transaction outcome at this point.

Active---The transaction has been started and is under way. It is not possible to change the transaction outcome at this point.

Committed---The transaction has committed and all participants have been notified. After a transaction commits, it is immediately removed from the list of transactions. It is not possible to change the transaction outcome at this point

Failed: the transaction is stopped

If transactions are executed serially, no transaction concurrency exists. However, if concurrent transactions with interleaving operations are allowed in an uncontrolled manner, some unexpected, undesirable result may occur.

Concurrency control ensures that database transactions are performed concurrently without violating the data integrity of the respective databases. Thus concurrency control is an essential element for correctness in any system where two database transactions or more, executed with time overlap, can access the same data. To ensure correctness, we need to guarantees that only serializable transaction schedules are generated, unless serializability is intentionally relaxed to increase performance, but only in cases where application correctness is not harmed.

Lock based protocol means that once one transaction is accessing the data, no other transaction is made to modify the data. So a locking protocol is a set of rules to be followed by each transaction to ensure that, even though actions of several

transactions might be interleaved, the net effect is identical to executing all transactions in some serial order.

Data items can be locked in two modes: 1.Exclusive (X) mode---Data item can be both read as well as written. X-lock is requested using lock-X instruction. 2. Shared (S) mode---Data item can only be read. S-lock is requested using lock-S instruction.