A transaction is a unit of program execution that accesses and possibly updates various data items.

Transaction can also be defined as; A set of actions which are considered to b e one atomic unit of task and are used to perform a task. If any error occurs during execution then transaction is aborted and changes a re undo; this is called rolled back of transaction. If all operations are completed successfully and reflected to database th en transaction is said to be committed. A transaction is said to be terminated if it is either committed or aborted.

A set of transaction is known as schedule.

A serial schedule is a schedule that considers all the actions of a transaction T1 followed by all the actions of another transaction T2 and so on.
A schedule whose effect on the state of the database is the same as the effec t of some serial schedule is called serializable schedule.
Transaction State: Active: the initial state. The transaction stays in this state while it is executing.

Partially committed; after the final statement of the transaction is executed.

Failed: After the discovery that normal execution can no longer proceed. Aborted: The state after the transaction has been rolled back and the database has been restored to its state prior to the start of the transaction. Committed: The state after successful completion of the transaction.

To ensure integrity of the data, we require that the database system maintain the follo wing properties of the transactions; Atomicity (All or None) . Either all operations of the transactions should be done properly or none. If for any reason an error occurs and the transaction is unable to complete all of its steps, the then system should be returned to the state it was in before the transaction was started. For example consider below transaction to transfer Rs. 50 from account A to account : 1. read(A)
2. 3. 4. 5. 6. A := A 50 write(A) read(B) B := B + 50 write(B)

In the above transaction if Rs. 50 is deducted from account A then it must be added to acc ount B otherwise it should not be deducted from A.

2.Consistency (Only valid data should be committed.) A transaction enforces consistency in the system state by ensurin g that at the end of any transaction the system is in a valid state.

If the transaction completes successfully, then all changes to the s ystem will have been properly made, and the system will be in a va lid state. If any error occurs in a transaction, then any changes already made will be automatically rolled back.
This will return the system to its state before the transaction was started. Since the system was in a consistent state when the transaction wa s started, it will once again be in a consistent state.

3.Isolation (Does not interfere with another)

Although multiple transactions may execute concurrently, each transaction must be unaware of other concurrently executing tra nsactions. When a transaction runs in isolation, it appears to be the only action that the system is carrying out at one time.

If there are two transactions that are both performing the same func tion and are running at the same time, transaction isolation will ensu re that each transaction thinks it has exclusive use of the system. This is important in that as the transaction is being executed, the sta te of the system may not be consistent.

The transaction ensures that the system remains consistent after the transaction ends, but during an individual transaction, this may not be the case. If a transaction was not running in isolation, it could access data from the system that may not be consistent. By providing transaction isolation, this is prevented from happening
4.Durability (Committed transaction will not be lost.)

After a transaction completes successfully, the changes it has made to the database should be permanent, even if there are system failures.
Durability ensures that any transaction committed to the database will not be lost. Durability is ensured through the use of database backups and transacti on logs that facilitate the restoration of committed transactions in spite of any subsequent software or hardware failures.

Serializability

Schedule 1 and Schedule 2 have different order of execution but result is same so this is known as serializabilty of transaction. If two transactions only read a data item then they do not conflict and order is not important. If two transactions either read or write completely separate data items then th ey do not conflict and order is not important. If one transaction writes a data item and another reads or writes same data ite m, order of execution is important.

Serializability
A serializable schedule has the same effect to the database as any serial schedule. Transactions are said to be serializable, if the results of running Transactions simultaneously are the same as the results of running them serially that is, one after the other. It is not important which transaction executes first, only that the res ult does not reflect any mixing of the transactions.

Conflict Serializability
Let

us consider schedule S which contains two consecutive instructions, Ii and Ij of transactions Ti and Tj.

If Ii and Ij refer to different data items then we can swap Ii and Ij witho ut affecting the results of any instruction in the schedule. We say that Ii and Ij are conflict instructions if they are instructions of different transactions on the same data item and at least one of these instructions is a write operation. If one or both instructions perform write and we change order of these two instructions then it is natural that one of the two will get wrong data.

Two schedules

S and S are said to be conflict equivalent if a sche dule S can be transformed into a schedule S by a series of swaps of nonconflicting instructions. A schedule S is conflict serializable if it is conflict equivalent to a serial schedule.

In above example, the Write(A) instruction of transaction T1 conflicts with Read(A) instruction of transaction T2 because both t he instructions access same data A. But Write(A) instruction of transaction T2 conflict with Read(B)instr uction of transaction T1because both the instructions Access different data. Transaction T2 performs write operation in A and transaction T1 is reading B. So in above example in Schedule 3, two instructions Read(A) and Write(A) of transaction T2 and two instructions Read(B) and Write(B) of transaction T1 are interchanged and we get Schedule 4. Therefore Schedule 3 is conflict serializable.

View Serilaizability Viewserializability of

a schedule is defined by equivalence to a serial schedule (no overlapping transactions) with the same transactions, such that respective transactions in the two schedules read and write the same data values ("view" the same data values).

Two schedules are view equivalent if in both schedules

1.Each transaction reads the same value. (the value produced by the same transaction) 2.The final write on each data item is the same. (was performed by the same transaction)

A schedule is view serializable if it is view equivalent to a serial sche dule. Two schedules S and S are said to be view equivalent if three con dition are met; 1.For each data item Q, if transaction Ti reads the initial value of Q in schedule S, then transaction Ti must also read the initial value of Q in schedule S. 2.For each data item Q, if transaction Ti reads value of Q which was produced by transaction Tj in schedule S then Ti must read the value of Q produced by Tj in schedule S. 3.For each data item Q, if transaction Ti performs the final write(Q) in schedule S then Ti must perform the final write(Q) in schedule S.

Condition 1 and 2 ensure

that each transaction reads the same valu

es in both schedules and therefore performs the same computation.

Condition 3 coupled with condition 1 and 2 ensures that both sched ules result in the same final system state. Every conflict serializable schedule is also view serializable but there are view serializable schedules that are not conflict serializable. Below is a schedule which is view serializable but not conflict serializable.

Schedule 6 is not conflict serializable because every pair of cons ecutive instructions conflicts and thus no swapping of instruction s is possible. T4 and T6 perform write(Q) operations without having performed a read(Q) operation. Writes of this sort are called blind writes.

Testing for Serializability (Conflict Serializability) Let S be a schedule, we construct a directed graph called a precedence graph from S. This graph consists of a pair G=(V,E) where V is a set of vertices(nodes) and E is a set of edges. The set of vertices consists of all the transactions participating in the schedule.

The set of edges consists of all edges Ti->Tj for which one of three conditions holds
1. Ti executes write(Q) before Tj executes read(Q) 2. Ti executes read(Q) before Tj executes write(Q) 3. Ti executes write(Q) before Tj executes write(Q) If an edge Ti->Tj exists in the precedence graph, then in any serial schedule S equivalent to S, Ti must appear before Tj. If precedence graph contains cycle then schedule is not conflict serializable otherwise it is conflict serializable. For Example; Schedule 1 & 2 are conflict serializable where as Schedule 3 is not conflict serializable.

LockBased Protocols One way to ensure isolation is to require that data items be accesse d in a mutually exclusive manner;

That is, while one transaction is accessing a data item, no other transaction can modify that data item.
The most common method used to implement this requirement is to allow a transaction to access a data item only if it is currently holding a lock on that item.

Locks 1. There are various modes in which a data item may be locked; 1.Shared. If a transaction Ti has obtained a sharedmode lock (denoted by S) on item Q then Ti can read but cannot write Q. 2.Exclusive. If a transaction Ti has obtained an exclusivemode lock (denoted by X) on item Q, then Ti can both read and write Q. Locking Protocol : Each transaction in the system follow a set of rules called a locking protocol indicating when a transaction my lock and unlock each of the data items. Locking protocols restrict the number of possible schedules.

Two Phase Commit Protocol

The twophase commit protocol provides an automatic recovery mechanism in case a system or media failure occurs during execution of the transaction. The twophase commit protocol ensures that all participating database servers receive and implement the same action (either to commit or to roll back a transaction), regardless of local or network failure.
If any database server is unable to commit its portion of the transaction, all database servers participating in the transaction must be prevented from committing their work. In two phase commit protocol there is one node which is act as a coordinator and all other participating node are known as cohorts (participants).

The protocol is initiated by the coordinator after the last step of the transaction has been re ached. The cohorts then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the cohort.

There are two phases of twophase commit protocol 1. Commit request phase or Voting phase or Pre commit phase
1.The coordinator sends a query to commit message to all cohorts and waits until it has received a reply from all cohorts. 2. The cohorts execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log. 3. Each cohort replies with an agreement message (cohort votes Yes to commit), if the cohort's actions succeeded, or an abort message (cohort votes No, not to commit), if the cohort experiences a failure that will make it impossible to commit.

2. Commit phase or Completion phase I .Success: If the coordinator received Yes from all cohorts during the commitrequest phase: 1. The coordinator sends a commit message to all the cohorts. 2.Each cohort completes the operation, and releases all the locks and resources held during the transaction. 3.Each cohort sends an acknowledgment to the coordinator. 4.The coordinator completes the transaction when all acknowledgments have been received.

II. Failure: If any cohort votes No during the commitrequest phase: 1. The coordinator sends a rollback message to all the cohorts. 2. Each cohort undoes the transaction using the undo log, and releases the resources and locks held during the transaction. 3. Each cohort sends an acknowledgement to the coordinator. 4.The coordinator undoes the transaction when all acknowledgements have been received.