Solved question Paper

Questions
What do you understand by the term
“TRANSACTION” in a database?

A transaction is defined as unit of work in a database system. It accesses and possibly modifies
various data objects like tuples, relations etc. Database systems that deal with large number of
transactions is called transaction processing systems. A transaction is a unit of data processing.
A transaction would involve manipulation of one or more values in database. Some
transactions can do writing of data without reading a data value.

Examples of transactions at a bank: withdrawal or deposit of money, transfer of money from

one account to another account.

Example 1: pseudo code for transaction to withdraw amount from an account ‘X’ :

; Assume that we are doing this transaction for person whose account number is X.
TRANSACTION WITHDRAWAL (withdrawal_amount)

Begin transaction

IF X exist then

READ X.balance

If X.balance > withdrawal_amount

THEN SUBTRACT withdrawal_amount

WRITE X.balance

COMMIT

ELSE
 DISPLAY “TRANSACTION CANNOT BE PROCESSED”
ELSE DISPLAY “ACCOUNT X DOES NOT EXIST”
End transaction
Example 2: Pseudo code for transaction to transfer amount from one account to another
account
; transfers transfer_amount from x’s account to y’s account
; assuming both accounts exist
TRANSACTION (x, y, transfer_amount)
Begin transaction
If X AND Y exist then
READ x.balance

If x.balance > transfer_amount THEN

x.balance=x.balance-transfer_amount

READ y.balance

y.balance=y.balance+transfer_amount

COMMIT

ELSE DISPLAY (“BALANCE IN X NOT OK”)

ROLLBACK
 ELSE DISPLAY (“ACCOUNT X OR Y DOES NOT EXIST”)

End transaction

COMMIT makes sure that all the changes made by transactions are made permanent.

ROLLBACK terminates the transactions and rejects any changes made by the transaction.
Discuss the properties of the
transactions.

A transaction has 4 desired properties (ACID properties). They are :

• Atomicity

• Consistency

• Isolation or Independence

• Durability or permanence

The ACID properties provides a mechanism to ensure correctness and consistency of a

database.

Atomicity : It defines transaction as an atomic unit of work and it has to be done completely or
not at all. Its maintained by transaction management component in DBMS.Example next slide.
 If the transaction fails after completion
Before: X: 1000 Y: 500 of T1 but before completion of T2.( say,
Transaction T after write(X) but before write(Y)), then
amount has been deducted from X but not
T1 T2
added to Y. This results in an inconsistent
database state. Therefore, the transaction
Read(X) Read(Y)
must be executed in entirety in order to
X:=X-100 Y:=Y+100 ensure correctness of database state.
Write(X) Write(Y)

After: X: 900 Y: 600

Consistency : : This property ensures that a complete transaction execution takes a database
from one consistent state to another consistent. If a transaction fails, even the databases
should come back to a consistent state.

Consider the example in atomicity,

The total amount before and after the transaction must be maintained.
Total before T occurs = 1000 + 500 = 1500.
Total after T occurs = 9000 + 600 = 1500.
Therefore, database is consistent. Inconsistency occurs in case T1 completes but T2 fails. As a
result T is incomplete.
Isolation or Independence : This property states that the updates of a transaction should not be
visible till they are committed. It guarantees that the progress of other transactions do not affect the
outcome of this transaction.
T1 T2
Let X=500, Y= 500
Read(X) Read(x)
Consider transaction T1 and T2 X:=X*100 Read(Y)
Write(X) Z:=X+Y
Read(Y) Write(Z)
Y:=Y-50
Write
Suppose T1 has been executed till Read (Y) and then T2 starts. As a result , interleaving of operations
takes place due to which T2 reads correct value of X but incorrect value of Y and sum computed by
T2: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of transaction:
T1: (X+Y = 50, 000 + 450 = 50, 450).
This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take place
in isolation and changes should be visible only after a they have been made to the main memory.
Durability : This property necessitates that once a transaction has committed the changes
made by it be never lost because of subsequent failure. Therefore, transaction is also a basic
unit of recovery.
Explain the states through which a
transaction passes during execution.

A transaction has many states of execution. These states are :

• Start state
• Execute state
• Abort/ Rollback state
• Commit state
A transaction is started as a program. From the start state as the transaction is scheduled by
the CPU it moves to the Execute state, however, in case of any system error at that point it may
also be moved into the Abort state. During the execution transaction changes the data values
and database moves to an inconsistent state. On successful completion of transaction it moves
to the commit state where the durability feature of transaction ensures that the changes will
not be lost. In case of any error the transaction goes to Rollback state where all the changes
made by the transaction are undone. Thus, after commit or rollback database is back into
consistent state. In case a transaction has been rolled back, it is started as a new transaction.
Start state - This is the initial state of every transaction. In this state the transaction is being
executed. For example, updating or inserting or deleting a record is done here. But it is still not
saved to the database.
Execute state - Once the transaction is scheduled by the CPU it moves from the start state to
the Execute state.
Abort state – When a system error occurs at the time of execution its moved to the abort state.
During the execution, transaction changes the data values and database moves to an
inconsistent state.
Committed – On successful completion of transaction, the transaction moves to the committed
state, unless it fails. In this state, all the transactions are permanently saved to the database.
This step is the last step of a transaction.
Rollback state -In case of any error the transaction goes to Rollback state where all the changes
made by the transaction are undone. After commit or rollback state, database is back into
consistent state. In case a transaction has been rolled back, it is started as a new transaction.
Write a short note on concurrency control./ What are
the problems encountered with concurrent transactions
? Explain through examples.

Execution of multiple transactions simultaneously is called concurrent transactions. It’s the

process of managing simultaneous execution of transactions in a shared database, to ensure
the serialisability of transactions.

Purpose of concurrency control :

1. To enforce isolation (one transaction should not interleave with another transaction)

2. To preserve database consistency

3. To resolve read-write and write-write conflicts.(conflicting operations)

Why do we need concurrency control?

Let us consider Transactions T3 and T4. T3 reads the balance of account X and subtracts a
withdrawal amount of Rs. 5000. T4 reads the balance of account X and adds an amount of
Rs.3000.
Problems of Concurrent transactions :
1. Lost Updates: Update of one transaction is overridden by another transaction. Suppose the two
transactions T3 and T4 run concurrently and they happen to be interleaved in the following way.
Assume the initial vale of X to be 10000.
After the execution of both the transactions the value X is 13000 while the semantically correct
value should be 8000. The problem occurred as the update made by T3 has been overwritten by
T4. The root cause of the problem is that one of the updates has been lost and we say that lost
update has occurred.
Another way in which the lost updates occur are:

Here T5 and T6 updates the same item X. Thereafter T5 decides to undo its action and rolls back
causing the value of X to 2000. In this case the update performed by T6 has got lost and a lost
update is said to have occurred.
Unrepeatable reads : If transaction T1 reads an item twice and the item is changed by an
another transaction T2 between the two reads hence T1, finds two different values on its two
reads. Suppose T7 reads X twice during its execution. If it did not update X itself it could be very
disturbing to see a different value of X in its next read. But this occurs if, there is an update
operation between the two read operations.

Thus, the inconsistent values are read and results of the transaction may be in error.
3. Dirty Reads : A transaction reads a value which has been updated by another transaction.
This update has not been committed and the later transaction aborts.

For example, T10 reads a value which has been updated by T9. This update has not been
committed and T9 aborts.

Here T10 reads a value that has been updated by transaction T9 that has been aborted. Thus
T10 has read a value that would never exist in the database and hence the problem. Here the
problem is isolation of transaction.
Inconsistent Analysis : The problem as shown with transactions T1 and T2 where two
transactions interleave to produce incorrect result during an analysis by Audit is an example of
such a problem. This problem occurs when more than one data items are being used for
analysis, while another transaction has modified some of those values and some are yet to be
modified. Thus an analysis transaction reads values from the inconsistent state of the database
that results in inconsistent analysis.
From the above problems, we can conclude that the prime reason for the problems of
concurrent transaction is that a transaction reads an inconsistent state of the database that has
been created by other transactions.
These problems cannot occur if the transaction do not read the same data values. The conflict
occurs only if 1 transaction updates a data value while another is reading or writing the data
value.
Common technique to overcome this is to restrict access to data items that are being read or
written by one transaction and is being written by another transaction. This technique is known
as locking.
Explain serializable scheduling.

Serialisability theory was developed to determine if concurrency problems have occurred when
two operations conflict with each other. Serialisability theory attempts to determine the
correctness of the schedules.

A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the

same ‘n’ transactions.

A serial schedule is a schedule in which execution of the transactions is in a serial order. All the
transactions in the schedule are executed one after the other. i.e. after one transaction is
completed, another transaction begins its execution. A schedule where operations are
executed without being interleaved (mixed with each other ) . A serial schedule is a schedule in
which either transaction T1 is completely done before T2 or transaction T2 is completely done
before T1.

As the schedule is executed in a serial manner, no inconsistency is possible. Serial order leads to
lesser throughput.
Example :

T1->T2 T2->T1
 An interleaved execution of T1 and T2

Schedule T1 T2
Read (A) Read(A)
Read(B) Read(B)
Write(B) Write(B)
Write(A) Write(A)

Now, we have to find whether this interleaved schedule would be performing read and write in
the same order as that of a serial schedule. If it’s the same, then its equivalent to a serial
schedule otherwise its not. If its not equivalent to a serial schedule, then it may result in
problems due to concurrent transactions.
Serialisability : Any schedule that produces the same results as a serial schedule is called a
serializable schedule.

How to find if a schedule is serializable or not?

By using the notion of precedence graph, an algorithm is devised to determine whether an

interleaved schedule is serializable or not. In the precedence graph, the transactions of the
schedule are represented as nodes. It also contains directed edges. An edge from the node
representing transactions Ti to node Tj means that there exists a conflicting operation between
Ti and Tj and Ti precedes Tj in some conflicting operations.

A serializable schedule is the one that contains no cycle in the graph.

Steps to construct a precedence graph :

1. Create a node for every transaction in the schedule.

2. Find the precedence relationships in conflicting operations. Conflicting operations can be :
(read-write) or (write-read) or (write-write) on the same data item in two different
transactions.
1. For a transaction Ti which reads an item A, find a transaction Tj that writes A later in the schedule. If
such a transaction is found, draw an edge from Ti to Tj.
2. For a transaction Ti which has written an item A, find a transaction Tj later in the schedule that reads
A. If such a transaction is found, draw an edge from Ti to Tj.
3. For a transaction Ti which has written an item A, find a transaction Tj that writes A later than Ti. If
such a transaction is found, draw an edge from Ti to Tj.

3. If there is any cycle in the graph, the schedule is not serializable, otherwise, find the
equivalent serial schedule of the transaction by traversing the transaction nodes starting
from the node that has no input edge.
Example to construct precedence graph :
Step 1 : We draw the nodes for transactions T1 and T2. Number of nodes = Number of
transactions.

T1 T2

Step 2 : In the above schedule, transaction T2 reads data item X, which is subsequently written
by T1, so there is an edge from T2 to T1.

T1 T2
Step 3 : Also, T2 reads a data item Y, which is subsequently written by T1, thus there is an edge
from T2 to T1. This edge exists, so there is no need to redo it.

Step 4 : There is no cycle in the graph, thus this schedule is serializable.

The equivalent serial schedule would be T2 followed by T1.

Differentiate between Serial Schedule
and serializable schedule.

Serial Schedule Serialisable schedule

A schedule where operations are executed A schedule S of n transactions is serializable if
without being interleaved (mixed with each it is equivalent to some serial schedule of the
other ). same ‘n’ transactions.

No concurrency is allowed Concurrency is allowed.

Locking is not required because no other Locking mechanism is required because other
transaction can interfere with it. transactions can interfere with it.

less resource utilization and low throughput High throughput and resources are utilised
properly.
Example for serial schedule :
Explain locks.

Locks ensure that the interleaved concurrent transactions do not have any concurrency related
problem. A lock is a variable that is associated with a data item in the database. A lock can be
placed by a transaction on a shared resource that it desires to use. When this is done, the data
item is available for the exclusive use for that transaction i.e., other transactions are locked out
of that data item. When a transaction that has locked a data item does not desire to use it any
more, it should unlock the data item so that other transactions can use it. If a transaction tries
to lock a data item that is already locked by some other transaction, it cannot do so and waits
for the data item to be unlocked. The component of DBMS that controls and stores lock
information is called the Lock Manager.

There are two basic types of locks :

• Binary lock : This locking mechanism has two states for a data item : locked or unlocked.

• Multiple-mode locks : In this locking type each data item can live in three states read locked
or shared locked, write locked or exclusive locked or unlocked.
Binary locks :
Multiple mode locks :It offers two locks: shared locks and exclusive locks.

▪ Shared lock :

• It is requested by a transaction that wants to just read the value of data item.

• A shared lock on a data item does not allow an exclusive lock to be placed but permits any
number of shared locks to be placed on that item.

▪ Exclusive lock :

• It is requested by a transaction on a data item that it needs to update.

• No other transaction can place either a shared lock or an exclusive lock on a data item that
has been locked in an exclusive mode.
Explain 2-phase locking protocol.

It’s a concurrency control method in which locking and unlocking is done in two phases. The
two phases of two-phase locking protocol are :

Phase 1 : The lock acquisition phase or growing phase : If a transaction T wants to read an
object, it needs to obtain the S (shared) lock. If T wants to modify an object, it needs to obtain X
(exclusive) lock. No conflicting locks are granted to a transaction. New locks on items can be
acquired but no lock can be released till all the locks required by the transaction are obtained.

Phase 2 : Lock Release Phase or shrinking phase: The existing locks can be released in any order
but no new lock can be acquired after a lock has been released. The locks are held only till they
are required.

Normally the locks are obtained by the DBMS.

A 2 phase locking always results in serializable schedule. The 2PL protocol has been approved
for it correctness.
▪ There are two types of 2PL :

1. The Basic 2PL

2. Strict 2PL

The basic 2PL allows release of lock at any time after all the locks have been acquired.
The basic 2PL suffers from the problem that it can result into loss of atomic / isolation property
of transaction as theoretically speaking once a lock is released on a data item it can be modified
by anther transaction before the first transaction aborts or commits.

To avoid the above problem we use strict 2PL. The strict 2PL is graphically depicted below.
Basic disadvantage of strict 2PL is that it restricts concurrency as it locks the item beyond the
time it is needed by a transaction.

2PL solves the problem of concurrency and atomicity, but introduces another problem known
as deadlock.

How does 2PL guarantee serialisability?

Serializability is mainly an issue of handling write operation. Because any inconsistency may
only be created by write operation. Multiple reads on a database item can happen in parallel.
2-Phase Locking protocol restricts this unwanted read/write by applying exclusive lock.
Moreover, when there is an exclusive lock on an item it will only be released in shrinking phase.
Due to this restriction there is no chance of getting any inconsistent state.
TRANSACTIONS T1 AND T2 THAT OBEY 2PL
T1 T2

read_lock(Y); read_lock(X);

read_item(Y); read_item(X);

write_lock(X); write_lock(Y);

unlock(Y); unlock(X);

read_item(X); read_item(Y);

X:=X+Y; Y:=X+Y;

write_item(X); write_item(Y);

unlock(X); unlock(Y);

© Indira Gandhi National Open University

Transactions T1 and T2 that do not obey 2PL.
 Why is 2 phase locking needed ?

Need of 2 Phase Locking:

Binary locks or shared and exclusive locks in transaction does not guarantee serializability of
schedules on its own.
For example, consider a banking transaction where the read write locking rules are used, but
we get a non serializable schedule which give incorrect result. For example, consider a banking
transaction where the read write locking rules are used, but we get a non serializable schedule
which give incorrect result(below).

To ensure the serializability, we use two phase locking.

Differentiate between basic and strict
two phase locking.
Basic 2PL Strict 2PL
It allows release of lock at any time after all Strict-2PL does not release a lock after using
the locks have been acquired. it. Strict-2PL holds all the locks until the
commit point and releases all the locks at a
time.
It has cascading abort. Strict-2PL avoids cascading abort.
It has increased concurrency as the locks can It restricts concurrency as it locks the item
be released at any time after all the locks have beyond the time it is needed by a transaction.
been acquired.
atomic/isolation property may be lost. This is Atomic/ isolation property are retained.
because once a lock is released on a data item
it can be modified by another transaction
before the first transaction commits or aborts.
Draw the graph as shown under 2PL Draw the graph as shown under 2PL
Explain Deadlock and its prevention in
database system.

A deadlock is a condition that occurs when two or more different database tasks are waiting for
each other and none of the task is willing to give up the resources that other task needs.
Consider two transactions and a schedule involving these transactions :
T1 T2 Schedule
X_lock A X_lock A T1: X_lock A
X_lock B X_lock B T2: X_lock B
: : T1: X_lock B
: : T2: X_lock A
Unlock A Unlock A
Unlock B Unlock B
After T1 has locked A, T2 locks B and then T1 tries to lock B, but unable to do so and waits for T2 to
unlock B. Similarly, T2 tries to lock A but finds that it is held by T1 which has not yet unlocked it and
thus waits for T1 to unlock A. At this stage, neither T1 nor T2 can proceed since both of these
transactions are waiting for the other to unlock the locked resource. In such a situation, we say that a
deadlock has occurred, since two transactions are waiting for a condition that will never occur.

Deadlock detection :

Simple way to detect a state of deadlock is to draw a directed graph called a “wait for” graph. Wait
for graph is maintained by the lock manager of the DBMS. This graph G is defined by the pair (V,E)
where Vis a set of vertices/nodes and E is set of edges/arcs.Each transaction is represented by a node
and an arc from Ti->Tj, Ti is waiting for a data item/resource that is held by Tj.

When transaction Ti requests for a data item that is held by Tj then the edge Ti->Tj is inserted in the
“wait for” graph. This edge is removed when transaction Tj is no longer holding the data item needed
by transaction T1.A deadlock in the system of transaction occurs, if and only if the wait-for graph
contains a cycle. Deadlock can be detected by doing a periodic check for cycles in graph
 T1 T2

Wait for graph of T1 and T2

In the above figure, T1 and T2 are the two transactions. T1 and T2 are waiting for each other to
unlock a resource held by the other, forming a cycle, causing a deadlock problem.
Deadlock conditions :
A deadlock occurs because of the following conditions :
• Mutual exclusion : states that at least one resource cannot be used by more than one process at a
time. The resources cannot be shared between processes. A resource can be locked in exclusive
mode by only one transaction at a time.
• Non-preemption : A data item can only be unlocked by the transaction that locked it. No other
transaction can unlock it.
• Partial allocation : A transaction can acquire locks on database in a piecemeal fashion.
• Circular waiting : transactions lock part of data resources needed and then wait indefinitely to
lock the resource currently locked by other transactions. states that one process is waiting for a
resource which is being held by second process and the second process is waiting for the third
process and so on and the last process is waiting for the first process. It makes a circular chain of
waiting.
To prevent deadlock, one has to ensure that at least one of these transactions does not occur.
Deadlock Prevention :

Deadlock can be prevented by having the basic logic : not to allow circular wait to occur. In this
approach, some of the transactions are rolled back instead of letting them wait.

There exists two such schemes . These are :

• “Wait-die” scheme : Its based on non- preemptive technique. Its based on simple rule :

If Ti requests a database resource that is held by Tj

then if Ti has a smaller timestamp than that of Tj

it is allowed to wait;

else Ti aborts
A timestamp may be defined as a sequence number that is unique for each transaction.
Therefore, a smaller timestamp means an older transaction.

For example, assume that three transactions T1, T2 and T3 where generated in that sequence,
then if T1 requests for a data item which is currently held by transactions T2, it is allowed to
wait as it has a smaller time stamping than that of T1. However, if T3 requests for a data item
which is currently held by transaction T2, then T3 is rolled back (die).

Wait Die
T1 T2 T3
“Wound wait” scheme : Its based on a preemptive technique. Its based on a simple rule :

If Ti requests a database resource that is held by Tj

then if Ti has a larger timestamp(Ti is younger) than that of Tj

it is allowed to wait;

else Tj is wounded up by Ti.

For example, assume that there are three transactions T1, T2 and T3 were generated in that
sequence, then if T1 requests for a data item which is held by transaction T2, then T2 is rolled
back and data item is allotted to T1 as T1 has a smaller time stamping than that of T2. However,
if T3 requests for a data item which is currently held by transaction T2, then T3 is allowed to
wait.
 T1 T2 T3
Wound T2 Wait

Whenever any transaction is rolled back, it would not make a starvation condition. Both “wait-
die” and “wound-wait” scheme avoid starvation.
The number of aborts and rollbacks will be higher in wait-die scheme than in the wound-wait
scheme.
Problem with these is that they may result in unnecessary rollbacks.
Differentiate between Wait die and wound
wait protocols.
Wait die Wound wait
It’s a non-preemptive technique It’s a preemptive technique.
When Transaction Ti requests a data item that When transaction Ti requests a data item that
is held by Tj, Ti is allowed to wait only if it has a is held by transaction Tj, Ti is allowed to wait
timestamp smaller than hat of Tj (i.e. Ti is older only if it has a timestamp larger than Tj,
than Tj), otherwise Ti is rolled back (dies). otherwise Tj is wounded up by Ti.
Number of aborts and roll backs is more. Number of aborts and roll backs is less.
Example :assume that three transactions T1, assume that there are three transactions T1,
T2 and T3 where generated in that sequence, T2 and T3 were generated in that sequence,
then if T1 requests for a data item which is then if T1 requests for a data item which is
currently held by transactions T2, it is allowed held by transaction T2, then T2 is rolled back
to wait as it has a smaller time stamping than and data item is allotted to T1 as T1 has a
that of T1. However, if T3 requests for a data smaller time stamping than that of T2.
item which is currently held by transaction T2, However, if T3 requests for a data item which
then T3 is rolled back (die). is currently held by transaction T2, then T3 is
allowed to wait.
What is optimistic scheduling ? Explain the
three phases of optimistic scheduling.

Optimistic concurrency control is a method used to prevent concurrency related problems.

Basic logic behind this is to allow the concurrent transactions to update the data items
assuming that the concurrency related problem will not occur. However, we need to reconfirm
our view in the validation phase.

Optimistic concurrency control algorithm has the following phases :

1. Read phase : A transaction T reads the data items from the database into its private
workspace. All the updates of the transaction can only change the local copies of the data in
the private workspace.

2. Validate phase : Checking is done to confirm whether the read values have changed during
the time transaction was updating the local values. This is performed by comparing the
current database values to the values that were read in the private workspace. In case, the
values have changed the local copies are thrown away and the transaction aborts.
3. Write phase : If validation phase is successful the transaction is committed and updates are
applied to the database, otherwise the transaction is rolled back.

Some of the terms defined to explain optimistic concurrency control :

• Write-set(T) : all data items that are written by a transaction T.

• Read-set(T) : all data items are read by a transaction T

• Timestamps : for each transaction T, the start time and the end time are kept for all the
three phases.
Example : In this case both T1 and T2 get committed. Read set of T1 and Read Set of T2 are both
disjoint, also the Write sets are also disjoint and thus no concurrency occurs.
Discuss the multiversion technique for
concurrency control.

Multiversion concurrency control, is a concurrency control method commonly used by database

management systems to provide concurrent access to the database and in programming languages
to implement transactional memory. If someone is reading from a database at the same time as
someone else is writing to it, it is possible that the reader will see a half-written or inconsistent piece
of data. There are several ways of solving this problem, known as concurrency control methods. The
simplest way is to make all readers wait until the writer is done, which is known as a lock. This can be
very slow, so MVCC takes a different approach: each user connected to the database sees a snapshot
of the database at a particular instant in time. Any changes made by a writer will not be seen by
other users of the database until the changes have been completed.
When an MVCC database needs to update an item of data, it will not overwrite the old data with new
data, but instead marks the old data as obsolete and adds the newer version elsewhere. Thus there
are multiple versions stored, but only one is the latest. This allows readers to access the data that
was there when they began reading, even if it was modified or deleted part way through by someone
else. It also allows the database to avoid the overhead of filling in holes in memory or disk structures
but requires (generally) the system to periodically sweep through and delete the old, obsolete data
objects. For a document-oriented database it also allows the system to optimize documents by
writing entire documents onto contiguous sections of disk—when updated, the entire document can
be re-written rather than bits and pieces cut out or maintained in a linked, non-contiguous database
structure.
Read and write transactions are thus isolated from each other without any need for locking.
Writes create a newer version, while concurrent reads access the older version.

A drawback of this is that more storage is needed to maintain multiple versions of the database
items.