1. What are the properties of Transaction?

Long 5 marks
Ans. It is a set of operation. It can be read and write of operation. It is
single logical unit of work. After every transaction it execute commit
statemet.

Property of Transaction
1. Atomicity
2. Consistency
3. Isolation
4. Durability

Atomicity
 o It states that all operations of the transaction take place at once if
not, the transaction is aborted.
o There is no midway, i.e., the transaction cannot occur partially. Each
transaction is treated as one unit and either run to completion or is
not executed at all.

Atomicity involves the following two operations:

Abort: If a transaction aborts then all the changes made are not visible.

Commit: If a transaction commits then all the changes made are visible.

Example: Let's assume that following transaction T consisting of T1 and

T2. A consists of Rs 600 and B consists of Rs 300. Transfer Rs 100 from
account A to account B.

T1 T2

Read(A) Read(B)
A:=A-100 Y:=Y+100
Write(A) Write(B)

After completion of the transaction, A consists of Rs 500 and B consists of

Rs 400.

If the transaction T fails after the completion of transaction T1 but before

completion of transaction T2, then the amount will be deducted from A
but not added to B. This shows its should be done or back to the previous
state.

Consistency
o The integrity constraints are maintained so that the database is
consistent before and after the transaction.
o The execution of a transaction will leave a database in either its
prior stable state or a new stable state.
 o The consistent property of database states that every transaction
sees a consistent database instance.
o The transaction is used to transform the database from one
consistent state to another consistent state.

For example: The total amount must be maintained before or after the
transaction.

1. Total before T occurs = 600+300=900

2. Total after T occurs= 500+400=900

3. Therefore, the database is consistent. In the case when T1 is

completed but T2 fails, then inconsistency will occur.

Isolation
o It shows that the data which is used at the time of execution of a
transaction cannot be used by the second transaction until the first
one is completed.
o In isolation, if the transaction T1 is being executed and using the
data item X, then that data item can't be accessed by any other
transaction T2 until the transaction T1 ends.
o The concurrency control subsystem of the DBMS enforced the
isolation property.

Example :

Let X= 000, Y = 500.

Consider two transactions T and T”.

Suppose T has been executed till Read (Y) and then T’’ starts. As a result,
interleaving of operations takes place due to which T’’ reads the correct
value

of X but the incorrect value of Y and sum computed by

T’’: (X+Y, 000+500=500, 500)

is thus not consistent with the sum at end of the transaction:

T: (X+Y, 000 + 450 = 450, 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

they have been made to the main memory.

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.

Some important points:

Property Responsibility for maintaining properties

Atomicity Transaction Manager

Consistency Application programmer

Isolation Concurrency Control Manager

Durability Recovery Manager

Advantages of ACID Properties in DBMS:

1. Data Consistency: ACID properties ensure that the data remains consistent

and accurate after any transaction execution.

2. Data Integrity: ACID properties maintain the integrity of the data by ensuring

that any changes to the database are permanent and cannot be lost.

3. Concurrency Control: ACID properties help to manage multiple transactions

occurring concurrently by preventing interference between them.

4. Recovery: ACID properties ensure that in case of any failure or crash, the

system can recover the data up to the point of failure or crash.

Disadvantages of ACID Properties in DBMS:

1. Performance: The ACID properties can cause a performance overhead in the

system, as they require additional processing to ensure data consistency and

integrity.

2. Scalability: The ACID properties may cause scalability issues in large

distributed systems where multiple transactions occur concurrently.

4. Complexity: Implementing the ACID properties can increase the complexity of

the system and require significant expertise and resources.

Q2 .What is Concurrency Control ? Why Use it and Challenges.

Concurrency Control is the management procedure that is required for controlling

concurrent execution of the operations that take place on a database.
But before knowing about concurrency control, we should know about concurrent
execution.

Concurrent Execution in DBMS

 In a multi-user system, multiple users can access and use the same database
at one time, which is known as the concurrent execution of the database. It
means that the same database is executed simultaneously on a multi-user
system by different users.

 While working on the database transactions, there occurs the requirement of

using the database by multiple users for performing different operations, and
in that case, concurrent execution of the database is performed.

 The thing is that the simultaneous execution that is performed should be

done in an interleaved manner, and no operation should affect the other
executing operations, thus maintaining the consistency of the database. Thus,
on making the concurrent execution of the transaction operations, there
occur several challenging problems that need to be solved.

In a database transaction, the two main operations are READ and WRITE operations.
So, there is a need to manage these two operations in the concurrent execution of
the transactions as if these operations are not performed in an interleaved manner,
and the data may become inconsistent. So, the following problems occur with the
Concurrent Execution of the operations:

Problem 1: Lost Update Problems (W - W Conflict)

The problem occurs when two different database transactions perform the
read/write operations on the same database items in an interleaved
manner (i.e., concurrent execution) that makes the values of the items
incorrect hence making the database inconsistent.

For example:
Consider the below diagram where two transactions T X and TY, are
performed on the same account A where the balance of account A
is $300.

o At time t1, transaction TX reads the value of account A, i.e., $300 (only
read).
o At time t2, transaction T X deducts $50 from account A that becomes $250
(only deducted and not updated/write).
o Alternately, at time t3, transaction T Y reads the value of account A that will
be $300 only because TX didn't update the value yet.
o At time t4, transaction TY adds $100 to account A that becomes $400 (only
added but not updated/write).
o At time t6, transaction TX writes the value of account A that will be
updated as $250 only, as TY didn't update the value yet.
o Similarly, at time t7, transaction T Y writes the values of account A, so it will
write as done at time t4 that will be $400. It means the value written by
TX is lost, i.e., $250 is lost.

Hence data becomes incorrect, and database sets to inconsistent.

Dirty Read Problems (W-R Conflict)
The dirty read problem occurs when one transaction updates an item of
the database, and somehow the transaction fails, and before the data gets
rollback, the updated database item is accessed by another transaction.
There comes the Read-Write Conflict between both transactions.

For example:

Consider two transactions TX and TY in the below diagram

performing read/write operations on account A where the
available balance in account A is $300:

o At time t1, transaction TX reads the value of account A, i.e., $300.

o At time t2, transaction TX adds $50 to account A that becomes $350.
o At time t3, transaction TX writes the updated value in account A, i.e., $350.
o Then at time t4, transaction TY reads account A that will be read as $350.
o Then at time t5, transaction T X rollbacks due to server problem, and the
value changes back to $300 (as initially).
o But the value for account A remains $350 for transaction T Y as committed,
which is the dirty read and therefore known as the Dirty Read Problem.
Unrepeatable Read Problem (W-R Conflict)
Also known as Inconsistent Retrievals Problem that occurs when in a
transaction, two different values are read for the same database item.

For example:

Consider two transactions, TX and TY, performing the read/write

operations on account A, having an available balance = $300. The
diagram is shown below:

o At time t1, transaction TX reads the value from account A, i.e., $300.
o At time t2, transaction TY reads the value from account A, i.e., $300.
o At time t3, transaction T Y updates the value of account A by adding $100
to the available balance, and then it becomes $400.
o At time t4, transaction TY writes the updated value, i.e., $400.
o After that, at time t5, transaction T X reads the available value of account
A, and that will be read as $400.
o It means that within the same transaction T X, it reads two different values
of account A, i.e., $ 300 initially, and after updation made by transaction
TY, it reads $400. It is an unrepeatable read and is therefore known as the
Unrepeatable read problem.

Thus, in order to maintain consistency in the database and avoid such

problems that take place in concurrent execution, management is
needed, and that is where the concept of Concurrency Control comes into
role.

Concurrency Control Protocols

The concurrency control protocols ensure the atomicity, consistency,
isolation, durability and serializability of the concurrent execution of the
database transactions. Therefore, these protocols are categorized as:

o Lock Based Concurrency Control Protocol

o Time Stamp Concurrency Control Protocol
o Validation Based Concurrency Control Protocol

Q3. Procedure to Test the Serializability?

Serialization Graph is used to test the Serializability of a schedule.

Assume a schedule S. For S, we construct a graph known as precedence

graph. This graph has a pair G = (V, E), where V consists a set of vertices,
and E consists a set of edges. The set of vertices is used to contain all the
transactions participating in the schedule. The set of edges is used to
contain all edges Ti ->Tj for which one of the three conditions holds:

1. Create a node Ti → Tj if Ti executes write (Q) before Tj executes read (Q).

2. Create a node Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
3. Create a node Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

o 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.
 o 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.

For example:

Explanation:

Read(A): In T1, no subsequent writes to A, so no new edges

Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges
This is precedence graph for above example

Precedence graph for schedule S1:

The precedence graph for schedule S1 contains a cycle that's why

Schedule S1 is non-serializable.

Next Page
Explanation:

Read(A): In T4,no subsequent writes to A, so no new edges

Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges
This is precedence graph for above example

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why

ScheduleS2 is serializable.

Q5.D/B Serial and Serializable Schedule?

Serial Schedules Serializable Schedules

The serial schedule is a type of schedule The serializability of schedules is used

where one transaction is executed to find non-serial schedules that allow
completely before starting another the transaction to execute concurrently
transaction. In the serial schedule, when the without interfering with one another.
first transaction completes its cycle, then
the next transaction is executed.

No concurrency is controlled Concurrency is controlled

Serial Schedule leads to less resource Serializable Schedules improves both less
utilization and cpu throughput. resource utilization and cpu throughput.

Serial Schedule are less efficient as Serializable schedules are always better than
compared to serializable schedules. serial schedule

There is no concurrency or Serializable schedules allow for some

parallelism between transactions in degree of concurrency.
a serial schedule. Transactions are
isolated from each other

No interleaving or concurrency; Allows interleaving and concurrency

transactions are executed between transactions but ensures that
sequentially, one after the other. the final result is equivalent to some
serial order.