BISQL – Laymen to SQL Developer # 35 – Transaction Processing #2 – Desirable Properties of Transactions, Concepts of Schedule History, recoverable cascading rollback and script schedules

Hi Folks,

This post is part of Series Database Management Systems

Currently running topic for this series is listed as below :

Series of Database Management Systems

>>Chapter 1 : DBMS [Database Management Systems]

>>Chapter 2 : Database Core Concepts and  Applications

>>Chapter 3 : Record Storage and Primary File Organization

>>Chapter 4 : Index Structures of Files

>>Chapter 5 : Entity-Relationship Model

>>Chapter 6 : Relational Algebra

>>Chapter 7 : SQL

>>Chapter 8 : Functional Dependencies and  Normalization For Relational Databases

>>Chapter 9 : Transaction Processing <You are Here>

Continuing from my previous post on this series.

We are going to Cover the Following Points in this article

• Desirable Properties of Transactions
• Concepts of Schedule History, recoverable cascading rollback and script schedules

Desirable Properties of Transactions

To ensure data integrity, the database management system should maintain the following transaction properties. These are often called the ACID properties.

1. Atomicity: A transaction is an atomic unit of processing. It is either performed in its entirety (completely) or not performed at all.

2. Consistency: The basic idea behind ensuring atomicity is as follows.

The database system keeps back of the old values of any data on which a transaction performs a write, and if the transaction does not complete its execution, the old values are restored to make it appear as though the transaction was never executed.

For Ex: Let Ti be a transaction that transfers 850 from account A to account B. This transaction can be defined as

Ti ; read(A)

A :=A-50; Writ (A);

Read(B);

B:=B+50; Write (B).

Suppose that before execution of transactions Ti the values of accounts A and B are Rs.1000 and Rs.2000 respectively. Now suppose that, during the execution of transaction Ti, a failure has occurred after write(A) operation, that prevents Ti from completing its execution successfully. But before the write of B operation was executed values of A and B in database are Rs.950 and`Rs.2000. We have lost Rs.50 which is executed in a sequential fashion.

3. Durability: Once a transaction changes the database and the changes are committed, these changes must never be lost because of subsequent failures. The users need not worry about the incomplete transactions. Partially executed transactions can be rolled back to the original state, ensuring durability is the responsibility of the recovery management component of the DBMS.

Concepts of Schedule History, recoverable cascading rollback and script schedules

A schedule history: A schedule history can be defined as a partial order over the operations of a set of transactions.

Suppose T1, T2, T3 are the three transactions

H1 = {W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2 (z), C2, R3 (z), C3} Where as R1, R2, R3 are the read operations of T1, T2, T3, W1, W2, W3 are the write operations of T1, T2, T3 and C1, C2, C3 are the COMMIT operation of T1, T2, T3 respectively.

Recoverable cascading rollback: Recoverability is the ability to recover data from the transaction failure. The transactions which are committed will not read data written by the transactions aborted. This is because the transactions commit only after all the changes of the transaction they read ends with COMMIT. So they must read COMMIT.

For eg: Suppose in the below schedules

Here both S and S1 are recoverable schedules. In S transaction T1 commits before T2 transaction therefore the value read for x in T2 is correct. Later T2 will also commit and hence recoverable.

In S1, transaction T1 is aborted. Therefore, T2 has to abort itself since the value read for x in T2 in incorrect.

Therefore in bothe the case the consistency of the database is maintained. Consider another eg.

In this schedule S2 transaction T2 is read before T1 commits. Therefore the value for x in T2 is incorrect because T1 got aborted later. Still the T2 got committed. Therefore it is unrecoverable.

Cascading roll backs: The cascading effect means if one transaction happens to fail in a schedule it affects many to fail along with it. In this case

cascading roll back has to be taken place. Rollback is a process which makes the database status go back to the state before the failure transaction. It helps in maintaining integrity of the database.

A “ROLLBACK” command in SQL makes the status of the data rolled back to its state as it was before any changes were made.

Refer the example on recoverable schedules. In this example, although S1 is recoverable it cannot avoid cascading failures (aborts). When transaction T1 aborts, the transaction T2 will abort itself to maintain consistency.

Below is the example which shows a recoverable schedule which avoid cascading effect. But the updation of x by T1 is lost.

Script scheduler is part of schedule. During script schedule the script is executed in the duration of time by the schedules.

Hope you will like Series of Database Management Systems series !

If you have not yet subscribe this Blog , Please subscribe it from “follow me” tab !

So that you will be updated @ real time and all updated knowledge in your mail daily for free without any RSS subscription OR news reading !!

Happy Learning and Sharing !!

For More information related to BI World visit our all Mentalist networks Blog

SQL Server Mentalist … SQL Learning Blog

Business Intelligence Mentalist … Business Intelligence World

Microsoft Mentalist … MVC,ASP.NET, WCF & LinQ

MSBI Mentalist … MS BI and SQL Server

NMUG Bloggers …Navi Mumbai User Group Blog

Architectural Shack … Architectural implementation and design patterns

DBA Mentalist …Advance SQL Server Blog

MVC Mentalist … MVC Learning Blog

Link Mentalist … Daily Best link @ your email

Infographics Mentalist … Image worth explaining thousand Words

Hadoop Mentalist … Blog on Big Data

BI Tools Analysis … BI Tools

Connect With me on

| Facebook |Twitter | LinkedIn| Google+ | Word Press | RSS | About Me |