Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

Unit – 6 Transaction Processing and Concurrency Control, and Recovery

1. Show how lost update and incorrect summary problem might occur in concurrent executions of
transactions.
Lost Update Problem
The Lost Update problem arises when an update in the data is done over another update but by two
different transactions.
Example: Consider two transactions A and B performing read/write operations on a data DT in the
database DB. The current value of DT is 1000: The following table shows the read/write operations in A
and B transactions.

Time A B
T1 READ(DT) ------
T2 DT=DT+500 ------
T3 WRITE(DT) ------
T4 ------ DT=DT+300
T5 ------ WRITE(DT)
T6 READ(DT) ------

Transaction A initially reads the value of DT as 1000. Transaction A modifies the value of DT from 1000 to
1500 and then again transaction B modifies the value to 1800. Transaction A again reads DT and finds
1800 in DT and therefore the update done by transaction A has been lost.

Incorrect Summary Problem

The Incorrect summary problem occurs when there is an incorrect sum of the two data. This happens
when a transaction tries to sum two data using an aggregate function and the value of any one of the data
get changed by another transaction.
Example: Consider two transactions A and B performing read/write operations on two data DT1 and DT2
in the database DB. The current value of DT1 is 1000 and DT2 is 2000: The following table shows the
read/write operations in A and B transactions.

Time A B
T1 READ(DT1) ------
T2 add=0 ------
T3 add=add+DT1 ------
T4 ------ READ(DT2)
T5 ------ DT2=DT2+500
T6 READ(DT2) ------
T7 add=add+DT2 ------

Transaction A reads the value of DT1 as 1000. It uses an aggregate function SUM which calculates the sum
of two data DT1 and DT2 in variable add but in between the value of DT2 get changed from 2000 to 2500
by transaction B. Variable add uses the modified value of DT2 and gives the resultant sum as 3500 instead
of 3000.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

2. Discuss the ACID properties of a database transaction with suitable example.

A transaction is a single logical unit of work that accesses and possibly modifies the contents of a database.
Transactions access data using read and write operations.
In order to maintain consistency in a database, before and after the transaction, certain properties are
followed. These are called ACID properties.

Atomicity:
By this, we mean that either the entire transaction takes place at once or doesn’t happen at all. There is
no midway i.e. transactions do not occur partially. Each transaction is considered as one unit and either
runs to completion or is not executed at all. It involves the following two operations.
—Abort: If a transaction aborts, changes made to the database are not visible.
—Commit: If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.
Consider the following transaction T consisting of T1 and T2: Transfer of 100 from account X to account Y.

Consistency:
This means that integrity constraints must be maintained so that the database is consistent before and
after the transaction. It refers to the correctness of a database. Referring to the example above,
The total amount before and after the transaction must be maintained.

Total before T occurs = 500 + 200 = 700.

Total after T occurs = 400 + 300 = 700.

Therefore, the database is consistent. Inconsistency occurs in case T1 completes but T2 fails. As a result,
T is incomplete.

Isolation:
This property ensures that multiple transactions can occur concurrently without leading to the
inconsistency of the database state. Transactions occur independently without interference. Changes
occurring in a particular transaction will not be visible to any other transaction until that particular change
in that transaction is written to memory or has been committed. This property ensures that the execution
of transactions concurrently will result in a state that is equivalent to a state achieved these were executed
serially in some order.

Let X= 500, Y = 500.

Consider two transactions T and T”.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

Durability:
This property ensures that once the transaction has completed execution, the updates and modifications
to the database are stored in and written to disk and they persist even if a system failure occurs. These
updates now become permanent and are stored in non-volatile memory. The effects of the transaction,
thus, are never lost.

3. Draw a state diagram, and discuss the typical state that a transaction goes through during transaction.

States through which a transaction goes during its lifetime. These are the states which tell about the
current state of the Transaction and also tell how we will further do the processing in the transactions.

These are different types of Transaction States:

Active State – When the instructions of the transaction are running then the transaction is in active state.
If all the ‘read and write’ operations are performed without any error then it goes to the “partially
committed state”; if any instruction fails, it goes to the “failed state”.

Partially Committed – After completion of all the read and write operation the changes are made in main
memory or local buffer. If the changes are made permanent on the DataBase then the state will change
to “committed state” and in case of failure it will go to the “failed state”.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

Failed State – When any instruction of the transaction fails, it goes to the “failed state” or if failure occurs
in making a permanent change of data on Data Base.

Aborted State – After having any type of failure the transaction goes from “failed state” to “aborted state”
and since in previous states, the changes are only made to local buffer or main memory and hence these
changes are deleted or rolled-back.

Committed State – It is the state when the changes are made permanent on the Data Base and the
transaction is complete and therefore terminated in the “terminated state”.

Terminated State – If there isn’t any roll-back or the transaction comes from the “committed state”, then
the system is consistent and ready for new transaction and the old transaction is terminated.

4. Schedule, Serial Schedule, Non Serial Schedule, Serializable Schedule

Schedule, as the name suggests, is a process of lining the transactions and executing them one by one.
When there are multiple transactions that are running in a concurrent manner and the order of operation
is needed to be set so that the operations do not overlap each other, Scheduling is brought into play and
the transactions are timed accordingly.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

Serial Schedules:
Schedules in which the transactions are executed non-interleaved, i.e., a serial schedule is one in which
no transaction starts until a running transaction has ended are called serial schedules. i.e., In Serial
schedule, a transaction is executed completely before starting the execution of another transaction. In
other words, you can say that in serial schedule, a transaction does not start execution until the currently
running transaction finished execution. This type of execution of transaction is also known as non-
interleaved execution. The example we have seen above is the serial schedule.
Example: Consider the following schedule involving two transactions T1 and T2.

where R(A) denotes that a read operation is performed on some data item ‘A’ This is a serial schedule
since the transactions perform serially in the order T1 —> T2

Non-Serial Schedule:
This is a type of Scheduling where the operations of multiple transactions are interleaved. This might lead
to a rise in the concurrency problem. The transactions are executed in a non- serial manner, keeping the
end result correct and same as the serial schedule. Unlike the serial schedule where one transaction must
wait for another to complete all its operation, in the non-serial schedule, the other transaction proceeds
without waiting for the previous transaction to complete. This sort of schedule does not provide any
benefit of the concurrent transaction. It can be of two types namely, Serializable and Non-Serializable
Schedule.

Serializable Schedule:
This is used to maintain the consistency of the database. It is mainly used in the Non-Serial scheduling to
verify whether the scheduling will lead to any inconsistency or not. On the other hand, a serial schedule
does not need the serializability because it follows a transaction only when the previous transaction is
complete. The non-serial schedule is said to be in a serializable schedule only when it is equivalent to the
serial schedules, for an n number of transactions. Since concurrency is allowed in this case thus, multiple
transactions can execute concurrently.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

5. How can you test a schedule for conflict serializability?

A schedule is called conflict serializable if it can be transformed into a serial schedule by swapping non-
conflicting operations.

Algorithm for testing conflict serializability schedule S:

- Look at only read_Item(x) and write_Item(x) operations.

- Construct a precedence graph – a graph with directed edges.

- An edge is created from Ti to Tj if one of the operations in Ti appears before a conflicting operation in Tj.

- The schedule is serializable if and only if the precedence graph has no cycles.

6. How can you test the serializability?

To test the serializability of a schedule, we can use Serialization Graph or Precedence Graph. A serialization
Graph is nothing but a Directed Graph of the entire transactions of a schedule.

It can be defined as a Graph G(V, E) consisting of a set of directed-edges E = {E1, E2, E3, ..., En} and a set
of vertices V = {V1, V2, V3, ...,Vn}. The set of edges contains one of the two operations - READ, WRITE
performed by a certain transaction.

Ti -> Tj, means Transaction-Ti is either performing read or write before the transaction-Tj.

- If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti are executed before
the first instruction of Tj is executed.

- If a precedence graph for schedule S contains a cycle, then S is non-serializable. If the precedence graph
has no cycle, then S is known as serializable.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

7. What is concurrency control? Name various methods of controlling the concurrency control?
Concurrency control concept comes under the Transaction in database management system (DBMS). It is
a procedure in DBMS which helps us for the management of two simultaneous processes to execute
without conflicts between each other, these conflicts occur in multi user systems.

Concurrency can simply be said to be executing multiple transactions at a time. It is required to increase
time efficiency. If many transactions try to access the same data, then inconsistency arises. Concurrency
control required to maintain consistency data.

For example, if we take ATM machines and do not use concurrency, multiple persons cannot draw money
at a time in different places. This is where we need concurrency.

Concurrency control techniques:

a. Two-Phase Locking Protocol: Locking is an operation which secures: permission to read, OR permission
to write a data item. Two phase locking is a process used to gain ownership of shared resources without
creating the possibility of deadlock.
Two phase locking prevents deadlock from occurring in distributed systems by releasing all the resources
it has acquired, if it is not possible to acquire all the resources required without waiting for another
process to finish using a lock. This means that no process is ever in a state where it is holding some shared
resources, and waiting for another process to release a shared resource which it requires. This means that
deadlock cannot occur due to resource contention. A transaction in the Two Phase Locking Protocol can
assume one of the 2 phases:

(i) Growing Phase: In this phase a transaction can only acquire locks but cannot release any lock. The point
when a transaction acquires all the locks it needs is called the Lock Point.

(ii) Shrinking Phase: In this phase a transaction can only release locks but cannot acquire any.

- Strict 2-PL: This requires that in addition to the lock being 2-Phase all Exclusive(X) locks held by the
transaction be released until after the Transaction Commits.
Following Strict 2-PL ensures that our schedule is:
• Recoverable
• Cascadeless
Hence, it gives us freedom from Cascading Abort which was still there in Basic 2-PL and moreover
guarantee Strict Schedules but still, Deadlocks are possible!

- Rigorous 2-PL:
This requires that in addition to the lock being 2-Phase all Exclusive(X) and Shared(S) locks held by the
transaction be released until after the Transaction Commits. Following Rigorous 2-PL ensures that our
schedule is:
• Recoverable
• Cascadeless
Hence, it gives us freedom from Cascading Abort which was still there in Basic 2-PL and moreover
guarantee Strict Schedules but still, Deadlocks are possible!
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

- Conservative 2-PL:
This protocol requires the transaction to lock all the items it accesses before the Transaction begins
execution by predeclaring its read-set and write-set. If any of the predeclared items needed cannot be
locked, the transaction does not lock any of the items, instead, it waits until all the items are available for
locking.

b. Time Stamp Ordering Protocol: A timestamp is a tag that can be attached to any transaction or any
data item, which denotes a specific time on which the transaction or the data item had been used in any
way. A timestamp can be implemented in 2 ways. One is to directly assign the current value of the clock
to the transaction or data item. The other is to attach the value of a logical counter that keeps increment
as new timestamps are required. The timestamp of a data item can be of 2 types:

(i) W-timestamp(X): This means the latest time when the data item X has been written into.

(ii) R-timestamp(X): This means the latest time when the data item X has been read from. These 2
timestamps are updated each time a successful read/write operation is performed on the data item X.

- Basic Timestamp Ordering :

• Whenever a Transaction T issues a W_item(X) operation, check the following conditions:
If R_TS(X) > TS(T) or if W_TS(X) > TS(T), then abort and rollback T and reject the operation. else,
Execute W_item(X) operation of T and set W_TS(X) to TS(T).

• Whenever a Transaction T issues a R_item(X) operation, check the following conditions:

If W_TS(X) > TS(T), then abort and reject T and reject the operation, else
If W_TS(X) <= TS(T), then execute the R_item(X) operation of T and set R_TS(X) to the larger of TS(T) and
current R_TS(X).

- Strict Timestamp Ordering:

A variation of Basic TO is called Strict TO ensures that the schedules are both Strict and Conflict
Serializable. In this variation, a Transaction T that issues a R_item(X) or W_item(X) such that TS(T) >
W_TS(X) has its read or write operation delayed until the Transaction T‘ that wrote the values of X has
committed or aborted.

8. What is Lock-based Protocol? Explain in short.

Lock Based Protocols in DBMS is a mechanism in which a transaction cannot Read or Write the data until
it acquires an appropriate lock. Lock based protocols help to eliminate the concurrency problem in DBMS
for simultaneous transactions by locking or isolating a particular transaction to a single user. Transactions
proceed only once the lock request is granted.

a. Shared Lock (S):

A shared lock is also called a Read-only lock. With the shared lock, the data item can be shared between
transactions. This is because you will never have permission to update data on the data item.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

For example, consider a case where two transactions are reading the account balance of a person. The
database will let them read by placing a shared lock. However, if another transaction wants to update that
account’s balance, shared lock prevents it until the reading process is over.

b. Exclusive Lock (X):

With the Exclusive Lock, a data item can be read as well as written. This is exclusive and can’t be held
concurrently on the same data item. X-lock is requested using lock-x instruction. Transactions may unlock
the data item after finishing the ‘write’ operation.

For example, when a transaction needs to update the account balance of a person. You can allow this
transaction by placing X lock on it. Therefore, when the second transaction wants to read or write,
exclusive lock prevents this operation.

9. Write about Deadlock Prevention.

In a database, a deadlock is an unwanted situation in which two or more transactions are waiting
indefinitely for one another to give up locks. Deadlock is said to be one of the most feared complications
in DBMS as it brings the whole system to a Halt. The DBMS is made to efficiently analyze every database
transaction, whether they can cause a deadlock or not, if any of the transactions can lead to a deadlock,
then that transaction is never executed.

Ways for preventing deadlocks are as follows:

- Wait-Die Scheme: When a transaction requests a resource that is already locked by some other
transaction, then the DBMS checks the timestamp of both the transactions and makes the older
transaction wait until that resource is available for execution.

- Wound-wait Scheme: When an older transaction demands a resource that is already locked by a younger
transaction (a transaction that is initiated later), the younger transaction is forced to kill/stop its
processing and release the locked resource for the older transaction's own execution. The younger
transaction is now restarted with a one-minute delay, but the timestamp remains the same. If a younger
transaction requests a resource held by an older one, the younger transaction is made to wait until the
older one releases the resource.
 Prepared by Prabesh Bhandari (For 3rd Sem BIT, TU)

10. Discuss starvation, and the different approaches to dealing with it.

Starvation or Livelock is the situation when a transaction has to wait for an indefinite period of time to
acquire a lock. Starvation can be best explained with the help of an example –

Suppose there are 3 transactions namely T1, T2, and T3 in a database that is trying to acquire a lock on
data item ‘ I ‘. Now, suppose the scheduler grants the lock to T1(maybe due to some priority), and the
other two transactions are waiting for the lock. As soon as the execution of T1 is over, another transaction
T4 also comes over and requests a lock on data item I. Now, this time the scheduler grants lock to T4, and
T2, T3 has to wait again. In this way, if new transactions keep on requesting the lock, T2 and T3 may have
to wait for an indefinite period of time, which leads to Starvation.

Solutions to starvation:

Increasing Priority – Starvation occurs when a transaction has to wait for an indefinite time, In this
situation, we can increase the priority of that particular transaction/s. But the drawback with this solution
is that it may happen that the other transaction may have to wait longer until the highest priority
transaction comes and proceeds.

Modification in Victim Selection algorithm –

If a transaction has been a victim of repeated selections, then the algorithm can be modified by lowering
its priority over other transactions.

First Come First Serve approach –

A fair scheduling approach i.e FCFS can be adopted, In which the transaction can acquire a lock on an item
in the order, in which the requested the lock.

Wait-die and wound wait scheme –

These are the schemes that use the timestamp ordering mechanism of transactions.