TRANSACTION MANAGEMENT AND CONCURRENCY CONTROL

.
70. What are the Transaction Properties? Or list and discuss the four transaction
properties.

Transaction:
A transaction is any action that reads from and / or writes to a database. A
transaction may consists of a simple select statement to generate a list of table contents, it
may consists of update statements to change the values of attributes in various tables, it
may consists of insert statement to add rows to one or more tables, or it may consists of
combination of select, update and insert statements
In DBMS must ensure that the transactions 4 well accepted properties called as
ACID properties.

Atomicity
Meaning that the transaction cannot be subdivided, and hence, if must be processed
in its entirety or not at all. Once the whole transaction is processed, we say that the
changes are committed. If the transaction fails at any midpoint, we say that it has aborted.

Consistency
Means any database constraints that must be true before the transaction must also
be true after the transaction.

Isolation
Means changes to database are not revealed to users until the transaction is
committed.

Durability
Means changes are permanent. Thus, once a transaction is committed, no
subsequent failure of the database can reverse the effect of the transaction.

70 a)What is Serializability ?

The concurrent execution of several transactions yields consistent results. The

concurrent execution of transactions T1, T2 and T3 yields results that appear to have been
executed in serial order.
1) Individual transactions are assumed to be correct
2) Running the transactions one at a time in any serial order is therefore also
correct
3) An interleaved execution is therefore correct if is equivalent to some serial
execution

70 b) How to Transaction management with SQL

Transaction support is provided by two SQL statements one is commit and another
one is rollback. Some SQL servers use transaction management statements such as “begin
transaction”.

71. What is Transaction Log and what are its functions.

The DBMS uses a transaction log to keep track of all transactions that update the
database. The information stored in this log is used by the DBMS for recovery requirement
triggered by rollback statement, a programs abnormal termination, or system failures, or
disk crash or network failure.
 DBMS automatically updates the transaction log, the transaction log stores:
1. A record for the beginning of the transaction.
2. Each transaction operations being performed update, delete, insert.
3. Name of the object effected by the transaction.
4. Before, after values for fields being update.
5. Ending commit of the transaction.
72. What is a concurrency Control? And what is its objective.

The simultaneous execution of a transaction in a multi user database system is

known as concurrency control. The objective of the concurrency control is to ensure the
serializability of transaction in a multi user database environment. In concurrency control
transaction over a shared database can create several data integrity and consistency
problems. The main three problems are:

 Lost Update.
 Un committed data
 Inconsistency Retrieval.
Lost Update

Ex: PRODUCT table attribute is PROD_QTY. the current PROD_QTY value is 35. Assume two
concurrency transactions T1 and T2 updates the PROD_QTY value for some time in the
PRODUCT table, the transactions are
T1 purchased 100 units. T2 sells 30 units.

Normal execution of two transactions is as follows.

Time Transaction Step Stored value

1 T1 PROD_QTY read 35
2 T1 PROD_QTY = 35 + 100
3 T1 Write PROD_QTY 135
4 T2 PROD_QTY read 135
5 T2 PROD_QTY = 135 – 30
6 T2 Write PROD_QTY 105

The following table, lost update problem can arise if both the transactions are
executed concurrently.

Note: T1 has not at been committed, T2 execution begins. Therefore T2 still operate on
value 35 and its subtraction gives 5 in memory. T1 writes the value 135 to disk which is
promptly overwrite by T2. The addition of 100 units is lost during this process.

Time Transaction Step Stored value

1 T1 PROD_QTY read 35
2 T2 PROD_QTY read 35
3 T1 PROD_QTY = 35+100
4 T2 PROD_QTY =35-30
5 T1 Write PROD_QTY 135
6 T2 Write PROD_QTY 5

Un committed data
 T1, T2 transactions are executed concurrently and the first transaction T1 is rollback
after the completion of second transaction T2 has already accessed the uncommitted data,
thus violating the isolation property of transaction.

Time Transaction Step Stored value

1 T1 PROD_QTY read 35
2 T1 PROD_QTY = 35 + 100
3 T1 Write PROD_QTY 135
4 T1 ****ROLLBACK**** 35
5 T2 PROD_QTY read 35
6 T2 PROD_QTY = 35 – 30
7 T2 Write PROD_QTY 5

In the following table uncommitted data problem arise when the rollback is completed after
T2 has being executed.

Time Transaction Step Stored value

1 T1 PROD_QTY read 35
2 T1 PROD_QTY = 35 + 100
3 T1 Write PROD_QTY 135
4 T2 PROD_QTY read 135
5 T2 PROD_QTY = 135 – 30
6 T1 ****ROLLBACK**** 35
7 T2 Write PROD_QTY 105

Inconsistency Retrieval
When a transaction calculates some summary functions over a set of data while
other transactions are updating the data. The problem is that the transaction might read
some data before they are changed and other data after they are changed there by giving
inconsistent results.

Transaction 1 (T1) Transaction2 (T2)

Select sum(PROD_QTY) Update PRODUCT set PROD_QTY = PROD_QTY + 10
from PRODUCT; where PROD_CODE=P3;
Update PRODUCT set PROD_QTY = PROD_QTY - 10
where PROD_CODE=P4;
COMMIT;

PROD_CODE BEFORE AFTER

P1 8 8
P2 32 32
P3 15 15+10 = 25
P4 23 23-10=13
P5 8 8
P6 6 6
TOTAL 92 92
The concurrent execution of transactions results inconsistent retrievals.

Time Transaction Action Value Total

1 T1 Read P1 QTY 8 8
2 T1 Read P2 QTY 32 40
3 T2 Read PROD_QTY for P3 15
4 T2 PROD_QTY = 15+10
5 T2 Write PROD_QTY 25
6 T1 Read P3 QTY 25 65
7 T1 Read P4 QTY 23 88
8 T2 Read PROD_QTY for P4 23
9 T2 PROD_QTY = 23-10
10 T2 Write PROD_QTY 13
11 T2 Commit
12 T1 Read P5 QTY 8 96
13 T1 Read P6 QTY 6 102

The computer answer is 102 which is wrong, the correct answer is 92.

73. Explain Concurrency control with locking methods.

All lock information is managed by a lock manager, which is responsible for assigning
and policing the locks used by the transactions. Lock granularity indicates the level of lock
used. One is database level, table level, page level, row level and field level.

Database Level
The entire database is locked thus preventing the use of any tables in the database
by T2 transaction while T1 transaction is being executed.

Table Level
The entire table is locked thus preventing access to any row by transaction T2 while
transaction T1 is using the table. If a transaction requires access to several tables, each
table may be locked.

Page Level
The DBMS will lock an entire disk page. Page is the equivalent of a disk block, which
can be described as a directory addressable section of a disk.

Row Level
DBMS allows concurrent transactions to access different rows of the same table even
when the rows are located on the same page.

Field Level
Concurrent transaction to access the same row as long as they require the use of
different fields within that row.

Lock Types
There are two types. One is shared lock a technique that allows other transactions to
read but not update a record or other resources. It is also called read lock or S-lock. The
other is exclusive lock a technique that prevents another transaction from reading and
therefore updating a record until it is unlocked.

Two-phase Locking
 The two-phases are growing phase, shrinking phase.
Growing phase – in which transaction acquires all required locks with out un locking any
data. Once all locks have been acquired, the transaction is in its locked point.
Shrinking phase – in which a transaction releases all locks and can not obtain any new
lock.
The two-phase locking protocol is governed by the following rules.
1. Two transactions can not have conflicting locks.
2. No unlock operation can precede a lock operation in the same transaction.
3. No data are affected until all locks are obtained, i.e. until the transaction is in its locked
point.
4. Two phase locking increases the transaction processing cost and may cause additional
undesirable effects.

74. What is Deadlock and how can it avoid.

A deadlock occurs when two transactions wait for each other to unlock data.
Ex:
T1=access data item x and y.
T2=access data item y and x.

T1 has not unlocked data item y, T2 can not begin; if T2 has not unlocked data item
x, T1 can not continue. Consequently T1 and T2 wait indefinitely, such a deadlock is also
known as deadly embrace.

Deadlock Prevention
A transaction requesting a new lock is aborted when there is the possibility that
deadlock can occur. The transaction is aborted, all changes made by this transaction are
rolled back and all locks obtained by the transaction are released.

Deadlock Detection
If deadlock is found, one transaction is aborted, other transaction is continued. The
DBMS periodically tests the database for deadlocks.

Deadlock Avoidance
The transaction must obtain all of the lock it needs before it can be executed.

75. Explain Concurrency control with Time stamping method.

The time stamping approach to schedule concurrent transactions assigns a global,
unique time stamp to each transaction. The timestamp value produces an explicit order in
which transactions are submitted to the DBMS. The timestamp have two properties
uniqueness and monotonicity.
Uniqueness ensures that no equal time stamp values can exist. Monotonicity ensures
that time stamp values always increase.
The disadvantage of time stamping approach is each value stored in the database
requires two additional timestamp fields. One is last time field was read, another one is last
update. It increases the memory needs and the database processing overheads.
76. Explain Concurrency control with optimistic methods.
The optimistic approach is based on the assumptions that the majority of the
database operations don’t conflict. Using an optimistic approach, each transaction moves
through 2 or 3 phases. The phases are read, validation and write phases.
Read phase – the transaction read the database, executes the needed computations and
makes the updates to a private copy of the database values.

The optimistic approach is based on the assumption that the majority of the database
operations do not conflict. The optimistic approach requires instead, a transaction is
executed with out restrictions until it is committed. Using an optimistic approach, each
transaction moves through two or three phases, referred as read, validation and write.

READ PHASE: The transaction, reads the database executes the needed computations and
makes the updates to a private copy of the database values. All update operations of the
transaction are recorded in a temporary update file, which is not accessed by the remaining
transactions.

VALIDATION PHASE: The transaction is validated to ensure that the changes made will not
affect the integrity and consistency of the database. If the validation test is positive the
transaction goes to the write phase. If the validation test is negative, the transaction is
restarted and the changes are discarded.

WRITE PHASE: Changes are permanently applied to the database.

The optimistic approach is acceptable for most read or query database systems that
require few update transactions

77. What are the three levels of backup may be used in database recovery
management.
Database recovery restore database from a given state usually inconsistent to
previously consistent state, recovery techniques are based on atomic transaction property.
DBMS provide functions that allow the database administrator to schedule automatic
database backups to permanent secondary storage device. The levels of backup are:

Full backup – Full backup of the database.

Differential Backup – in which, only the last modification to the database are copied.

Transaction Log Backup – which backup only the transaction log operations that are not
reflect in a previous backup copy on the database.

78. Explain about database failures. Or What are the leading causes of Data loss?
Or What are the events that cause a database In become non-operational?
A wide variety of failures can occur in processing a data base, ranging from the input
of an incorrect data value to complete loss or destruction of the data base.

1. Software: Software failures may be traceable to the O.S., DBMS software’s,

application programs or virus.
2. Hardware: Memory chip errors, disk crashes, disk full errors.
3. Transactions: The system detects deadlocks and aborts one of the transactions.
 4. Programming Exemptions: Application programs or end users may rollback
transactions when certain conditions are defined.
5. External Factors: System suffers complete destruction due to fire, earth quake,
floods, etc.

79. What is Transaction Recovery?

Database transaction recovery focuses on the different methods used to recover a
database from an inconsistent to a consistent state by using the data in the transaction log.
There are four important concepts that affect the recovery process:

1. Write-a-head log protocol – The transaction logs are always written before any
database data are actually updated.
2. Redundant Transaction Logs – DBMS keeps several copies of the transaction log
to ensure the physical disk failure problems.
3. Database Buffers – A buffer is a temporary storage area in primary memory used
to speed up disk operations and to improve processing time. DBMS software reads
the data from the disk and stores a copy on the buffer. When a transaction updates
data it actually updates in the buffer only.
4. Check point – A database checkpoint is an operation in which the DBMS writes all of
its update buffers to disk. Every checkpoint operation is registered in the transaction
log.

Transaction recovery procedures are generally two techniques deferred-write and write-
through.
A “deferred-write” or “deferred update” defines; the transaction operations do
not immediately update the physical database. Instead only the transaction log is updated.
The database is physically updated only after the transaction reaches the commit point. If
the transaction aborts before it reaches to commit point, no changes need to be made to
the database since database never updated. The recovery process for all started and
committed transactions will follow these steps.

1. Identify the last checkpoint in the transaction log. This is the last transaction data
was physically saved to disk.
2. For a transaction that started and committed before the last checkpoint, nothing
needs to be done because the data are already saved.
3. For a transaction that performed a commit operation after the checkpoint, the DBMS
uses the transaction log records to redo the transaction and to update the database.
4. For any transaction that had a rollback operation after the last checkpoint or that
was left active before the failure occurred, nothing needs to be done because the
database was never updated.
 When the recovery procedure uses “write-through” or “immediate update”, the
database is immediately updated by transaction operations during the transaction
execution, even the transaction reaches its commit point. If the transaction aborts before it
reaches its commit point, a rollback operation need to perform to restore the database.
The recovery process will follow the steps:

1. Identify the last checkpoint in the transaction log.

2. For a transaction that started and committed before the last checkpoint, nothing
needs to be dome, because the data already saved.
3. For a transaction that committed after the last check point, the DBMS redoes the
transaction.
4. For a transaction that had a rollback operation after the last checkpoint or that was
left active before the failure occurred, the DBMS uses the transaction log records to
rollback operations.
79) Explain Transaction state diagram?
Active state: This is the initial state of a transaction stays in this state while it is
starting execution.
Partially committed state: this transaction state occurs after the final statement of
the transaction has been executed
Failed state: the transaction state occurs after the discovery that normal execution can
no longer proceed.
Abort state: this transaction state occurs after the transaction has been rolled back and
the database has been restored to its state prior to the start of the transaction.
Committed state: this transaction state occurs after the successful completion of the
transaction