BISQL – Laymen to SQL Developer # 34 – Transaction Processing #1 – Introduction, Transaction Processing Concepts, Transactions in a Multiuser System

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

• Introduction
• Transaction Processing Concepts
• Transactions in a Multiuser System

Introduction

Transaction management is the ability of a database management system to manage the various transactions that occur within the system. Transaction is a set of program statements or collections of operations that form a single logical unit of work. A database management system should ensure that the transactions are executed properly, either the entire transaction should execute or none of the operations should have been executed. This is also called atomic cooperation. The DBMS should execute this task or transaction in total to avoid inconsistency.

Transaction Processing Concepts

Definition: A transaction is an atomic unit comprised of one or more SQL statements. A transaction begins with the first executable statement and ends when it is committed or rolled back.

Single User V/S Multi User systems: A DBMS is used if at most one user at a time can use the system. It is multi-user if many users can use the system and have access to the DB concurrently. For e.g.: An air line reservation system is used by 100′s of travel agency and clerks concurrently.

Multiple users can access databases and use computer systems simultaneously. Because of the concept of multiprogramming, this system executes some commands from one process than suspend that process, and executes some command from the next process. Therefore it is inter leaved.

In a single user system one can execute at most one process at a time.

Parallel execution of Operators C and D

Figure Interleaved concurrency versus parallel execution

The Read and Write operations and DBMS Buffers:

A transaction is a logical unit of database processing that includes one or more database access operations (insertion, delete etc). Only retrieving of data is called read only transaction.

The basic database access operations are

1) Read-item (x) –> It reads a database item named ‘x’ into a program variable.

2) Write-item (x) –> writes the value of the program variable x into the database.

Read-item (x) includes the following steps:

1. Find the address of the disk block that contains item ‘x’.

2. Copy that disk block into a bugger in main memory.

3. Copy item x from the buffer to the program variable x.

Executing the write-item (x) includes the following steps.

1. Find the address of the disk block that contains item (x).

2. Copy that disk block into a buffer in main memory.

3. Copy item x from the program variable into its current location in the buffer

4. Store the updated block from the buffer back to disk.

a. b. T1 T2

Read_item (X)

Read_item(X); X=X-N’ X:=X+M

Write_item(X);

Write_item(X)

Read_item(Y)

Y=Y+N;

Write_item(Y)

Concurrent control: The data in the database must perform their transactions concurrently without violation the ACID (Atomicity, Consistency, Integrity and Durability) properties of a database. It takes place during the progression of an activity. It involves the regulation of ongoing activities that are part of transformation process to ensure that they conform to organizational standards. Concurrency control solves the major issues involved with allowing multiple people simultaneous access to shared entities, and their object representations…

Why concurrency control is needed: In a multiuser database, transactions submitted by the various users may execute concurrently and may update the same data. Concurrently executing transactions must be guaranteed to produce the same effect as serial execution of transactions [one by one]. Several problems can occur when concurrent transactions execute in an uncontrolled manner, therefore the primary concern of a multiuser database includes how to control data concurrency and consistency.

Data concurrency: Access to data concurrently (simultaneously) used by many users must be co-ordinates.

Data consistency: A user always sees a consistent (accurate) view of all data committed by other transactions as of that time and all changes made by the user up to that time. Several problems can occur when concurrent transactions execute in an uncontrolled manner.

For e.g.: Airline reservation database in which a record is stored for each flight. Each record includes the number of reserved seats on that flight. Fig..a shows a Transaction "T1" that transfers N reservations from one flight, whose number of reserved seats is ‘x’, to another flight whose number of reserved seats is ‘y’. Fig.b shows a transaction T2 that reserves m seats on the first flight. We now discuss the types of problems we may encounter when these two transactions run concurrently.

1. The lost update problem: Suppose transactions T1 and T2 are submitted at the same time, when these two transactions are executed concurrently as shown in fig. a, then the final value of x is incorrect. Because T2 reads the value of x before T1 changes it in the database, and hence the updated value resulting from T1 is lost. For e.g.: x=80 at the start (80 reservation at the beginning), n=5 (T1 transfers 5 seat reservation from the flight x to y), and m=4 (T2 reserves 4 seats on x), the final result should be x=79 but due to interleaving of operations x=84, because updating T1 that removed the 5 seats from x was lost.

T1 T2

Read-item(x)

X;=x-n Read_item(x) X: = x+m

Write-item (x);

Read-item (y) Write_item(x): -Item x has an incorrect

Because its update by T1 is lost.

Y:=y+n; Write_item(y):

2. Dirty read problem: This problem occurs when one transaction updates a database item and then the transaction fails for some reason. The updated item is accessed by another transaction before it is changed back to its original value.

For e.g.: T1 updates item x and then fails before completion, so the system must change x back to original value. Before it can do so, however, transaction T2 reads the temporary value of x, which will not be recorded permanently in the database, because of the failure of T1. The value of item x that is read by T2 is called Dirty Data, because it has been created by a transaction that has not been completed and committed yet. Hence this problem is also known as the temporary update problem.

T1 T2

Read-item (x); X:=x-n

Write_item(x)

Read_item(x); X:=x+m;

write-item(x)

read_item(y);

3. Incorrect Summary Problem: If one transaction is calculating an aggregate summary function on a number of records, while other transactions are updating some of these records, the aggregate function may calculate some values before they are updated and others after they are updated.

For ex: Transaction T3 is calculating the total no. of reservations on all the flights, meanwhile transaction T1 is executing. The T3 reads the values of x after n seats have been subtracted from it, but reads the value of y before those n seats have been added to it.

T1 T3

Sum :=0

Read_item(A); Sum:=sum+A;

Read_item(x); X:=x-n’

Wrote_ote,(x); Read_item(x); T3 reads x after m os sintracted

Sum: = sum+x; and reads y before n is added, Read_item (y); so a wrong summary is the

Sum:=sum+y; result.

Read_item(y); Y:=y+n; Write_item(y)

Why is recovery needed?

A major responsibility of the data base administrator is to prepare for the possibility of hardware, software, network and system failure. It is usually desirable to recover the databases and return to normal operation as quickly as possible. Recovery should proceed in such a manner to protect the database and users from unnecessary problems.

Whenever a transaction is submitted to a DBMS for execution, the system is responsible for making sure that either.

1. All the operations in the transactions are completed successfully and their effects are recorded permanently in the DB or

2. The transaction has no effect on the DB; this may happen if a transaction fails after executing some of it’s operations, but before executing all of them.

Types of failures:

1. A computer failure (System Crash):

Hardware, software, network error occurs in the computer system during transaction

2. Transaction or system error:

Some operation in the transaction may cause it to fail, such as integer overflow or division by ‘Zero’ etc.

3. Local errors or exception conditions detected by the transaction: During transaction execution, certain conditions may occur that perform cancellation of the transaction. For ex. Data for the transaction my not be found.

4. Concurrency control enforcement:

The concurrency control method may decide to abort the transactions, to be restarted later, because several transactions are in a state of deadlock.

5. Disk failure:

Some disk blocks may lose their data because of read or write malfunctions

6. Physical problems and catastrophes:

This refers to a list of problems that includes power or air conditioning failure, fire, theft, overwriting disks etc.

Transaction states and additional operations: A transaction is an atomic unit of work that is entirely completed or not done at all. For recovery purpose the system needs to keep track of when the transaction starts, terminates, commits or aborts. Hence the recovery manager keeps track of the following operations.

1. Begin transaction: This marks the beginning of transaction execution,

2. Read/Write: These specify read/write operation execution.

3. End transaction: This specifies that the read and write transaction operations have ended, and marks the end of the transaction execution. At this point it maybe necessary to check whether the changes can be permanently applied to the DB or aborted.

4. Commit transaction: This signals a successful end of the transaction, so that any changes executed by the transaction can be committed to the DB.

5. Roll Back: This signals that the transactions has ended unsuccessfully, so that any changes that the transaction may have applied to the database must be undone.

Fig. State transition diagram illustrating the states for transaction execution

Figure shows a state transition diagram that describes how a transaction moves through its execution states. A transaction goes into an active state immediately after it starts execution, where it can issue Read and Write operations. When the transaction ends, it moves to the partially committed state. At this point some recovery protocols need to ensure that there is no system failure. Once this check is successful, the transaction is said to have reached its commit point and enters the committed state.

However, a transaction can go to the failed state if one of the checks fails or if the transaction is aborted during its active state. The transaction may then have to be rolled back to undo the effect of its Write operations on the database. The terminated state corresponds to the transaction leaving the system or end of the transaction.

Transactions in a Multiuser System

Transaction is a process of exchange and changes made to the attributes in the database. The atomicity of the transaction is maintained in order to protect the integrity of the databases. The atomicity of the transaction means transactions are completely committed or completely rolled back.

A multiuser transaction means they have multiple users operating at the same interval of time. For eg. In the debit card operations, if a person shops in the mall and pays the bill in terms of debit card it hardly takes 0.01 second of time. The main task to be taken care is the coordination of the transaction between the accounts and should be atomic, or else the person’s account might be debited and the corporate current account of the retailer may not be credited.

In multiuser access it will be simply done by locking the database during the process of transaction. Updation request to that particular database at that particular instant of time will be postponed.

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 |