Transaction Processing Concept

By Ajai Kumar Maurya CSE Mob: 9335833415

 • The transaction is a set of logically related operation. It
contains a group of tasks.
• A transaction is an action or series of actions. It is
performed by a single user to perform operations for
accessing the contents of the database.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's
account. This small transaction contains several low-level tasks:

X's Account Y's Account

1.Open_Account(X) 1.Open_Account(Y)
2.Old_Balance = X.balance 2.Old_Balance = Y.balance
3.New_Balance = Old_Balance - 800 3.New_Balance = Old_Balance + 800
4.X.balance = New_Balance 4.Y.balance = New_Balance
5.Close_Account(X) 5.Close_Account(Y)

By Ajai Kumar Maurya CSE Mob: 9335833415

 Operations of Transaction
Following are the main operations of transaction

Read(X): Read operation is used to read the value of X from the database and stores it in a buffer
in main memory.
Write(X): Write operation is used to write the value back to the database from the buffer.
Let's take an example to debit transaction from an account which consists of following
operations:

By Ajai Kumar Maurya CSE Mob: 9335833415

 Operations of Transaction
1.1. R(X);
2.2. X = X - 500;
3.3. W(X);
Let's assume the value of X before starting of the transaction is 4000.
• The first operation reads X's value from database and stores it in a buffer.
• The second operation will decrease the value of X by 500. So buffer will contain 3500.
• The third operation will write the buffer's value to the database. So X's final value will be 3500.
But it may be possible that because of the failure of hardware, software or power, etc. that transaction may
fail before finished all the operations in the set.
To solve this problem, we have two important operations
Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.
By Ajai Kumar Maurya CSE Mob: 9335833415
 Transaction property
The transaction has the four properties. These are used to maintain consistency in a database,
before and after the transaction.
Property of Transaction
1. Atomicity
2. Consistency
3. Isolation
4. Durability

By Ajai Kumar Maurya CSE Mob: 9335833415

Atomicity
Means either all successfully or none

• It states that all operations of the transaction take place at once if not, the transaction is aborted.
• 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.

By Ajai Kumar Maurya CSE Mob: 9335833415

Atomicity
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.
After completion of the transaction, A consists of Rs 500 and B consists of Rs 400.
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 the inconsistent database state. In order to ensure correctness of
database state, the transaction must be executed in entirety.
By Ajai Kumar Maurya CSE Mob: 9335833415
 Consistency
• The integrity constraints are maintained so that the database is consistent
before and after the transaction.
• The execution of a transaction will leave a database in either its prior stable
state or a new stable state.
• The consistent property of database states that every transaction sees a
consistent database instance.
• 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
Therefore, the database is consistent. In the case when T1 is completed but T2 fails, then inconsistency will occur
By Ajai Kumar Maurya CSE Mob: 9335833415
 Isolation
• 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.

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

• The concurrency control subsystem of the DBMS enforced the isolation property.

By Ajai Kumar Maurya CSE Mob: 9335833415

Durability
• The durability property is used to indicate the
performance of the database's consistent state. It
states that the transaction made the permanent
changes.
• They cannot be lost by the erroneous operation of a
faulty transaction or by the system failure. When a
transaction is completed, then the database
reaches a state known as the consistent state. That
consistent state cannot be lost, even in the event of
a system's failure.
• The recovery subsystem of the DBMS has the
responsibility of Durability property.
By Ajai Kumar Maurya CSE Mob: 9335833415
 Example: Let Ti be a transaction that transfers $50 from account A to
account B. This transaction can be defined as
Ti: read(A);
A := A - 50;
write(A);
read(B);
B := B + 50;
write(B).

By Ajai Kumar Maurya CSE Mob: 9335833415

 States of Transaction

By Ajai Kumar Maurya CSE Mob: 9335833415

 In a database, the transaction can be in one of the following states

By Ajai Kumar Maurya CSE Mob: 9335833415

Active state

❖ The active state is the first state of every transaction. In this state, the

transaction is being executed.

❖ For example: Insertion or deletion or updating a record is done here. But all the

records are still not saved to the database

Partially committed
❖ In the partially committed state, a transaction executes its final operation, but the data is still not saved to
the database.
❖ In the total mark calculation example, a final display of the total marks step is executed in this state.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Committed
A transaction is said to be in a committed state if it executes all its operations successfully. In

this state, all the effects are now permanently saved on the database system.

Failed state
❖ If any of the checks made by the database recovery system fails, then the transaction is

said to be in the failed state.

❖ In the example of total mark calculation, if the database is not able to fire a query to fetch

the marks, then the transaction will fail to execute.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Aborted
❖ If any of the checks fail and the transaction has reached a failed state then the database
recovery system will make sure that the database is in its previous consistent state. If not then
it will abort or roll back the transaction to bring the database into a consistent state.
❖ If the transaction fails in the middle of the transaction then before executing the transaction,
all the executed transactions are rolled back to its consistent state.
❖ After aborting the transaction, the database recovery module will select one of the two
operations:
❖ Re-start the transaction
❖ Kill the transaction

By Ajai Kumar Maurya CSE Mob: 9335833415

Frame Title
When transaction enters the aborted state, at this point, the system has two options:

❖ It can restart the transaction, but only if the transaction was aborted as a result of some

hardware or software error that was not created through the internal logic of the transaction. A

restarted transaction is considered to be a new transaction.

❖ It can kill the transaction. It usually does so because of some internal logical error that can be

corrected only by rewriting the application program, or because the input was bad, or because

the desired data were not found in the database.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Schedule

By Ajai Kumar Maurya CSE Mob: 9335833415

 A series of operation from one transaction to another

transaction is known as schedule. It is used to preserve

the order of the operation in each of the individual

transaction.

By Ajai Kumar Maurya CSE Mob: 9335833415

By Ajai Kumar Maurya CSE Mob: 9335833415
 1. Serial Schedule
The serial schedule is a type of schedule where one transaction is executed completely
before starting another transaction. In the serial schedule, when the first transaction
completes its cycle, then the next transaction is executed.
For example: Suppose there are two transactions T1 and T2 which have some operations.
If it has no interleaving of operations, then there are the following two possible
outcomes:

By Ajai Kumar Maurya CSE Mob: 9335833415

 Example: Consider the following two transactions:- Let T1 and T2 be two transactions that
transfer funds from one account to another. Transaction T1 transfers $50 from account A to
account B. It is defined as
T1: read(A);
A := A - 50;
write(A);
read(B);
B := B + 50;
write(B).
Transaction T2 transfers 10 percent of the balance from account A to account B. It is defined
as
T2: read(A);
temp := A * 0.1;
A := A - temp;
write(A);
read(B);
B := B + temp;
write(B).

By Ajai Kumar Maurya CSE Mob: 9335833415

2. Non-serial Schedule
• If interleaving of operations is allowed, then there will be non-serial schedule.
• It contains many possible orders in which the system can execute the individual operations of the
transactions.
• In the given figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It has interleaving of
operations.

3. Serializable schedule
• The serializability of schedules is used to find non-serial schedules that allow the transaction to execute
concurrently without interfering with one another.
• It identifies which schedules are correct when executions of the transaction have interleaving of their
operations.
• A non-serial schedule will be serializable if its result is equal to the result of its transactions executed
serially.

By Ajai Kumar Maurya CSE Mob: 9335833415

By Ajai Kumar Maurya CSE Mob: 9335833415
By Ajai Kumar Maurya CSE Mob: 9335833415
By Ajai Kumar Maurya CSE Mob: 9335833415
 Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Serializability

By Ajai Kumar Maurya CSE Mob: 9335833415

 Testing of 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).

By Ajai Kumar Maurya CSE Mob: 9335833415

 Conflict Serializability
Conflict Instructions: Consider a schedule S in which there are two consecutive instructions
Ii and Ij , of transactions Ti and Tj , respectively (i6=j). If Ii and Ij operates on same data item
such as Q, then these instructions will be conflicting instructions if any one of the following
is satisfied.
(1) Ii = read(Q), and Ij = write(Q).
(2) Ii = write(Q), and Ij = read(Q).
(3) Ii = write(Q), and Ij = write(Q).
In all other cases, instructions Ii and Ij will be non-conflicting.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Conflict Serializability(Cont.)
Conflict equivalent: Two schedules S and S’ are said to be conflict equivalent if a

schedule S can be transformed in to a schedule S’ by using swapping of non-

conflicting instructions.

Conflict serializable: A schedule S is said to be conflict serializable if it is conflict

equivalent to a serial schedule.

Some examples: Example: Check schedule-1, schedule-2, schedule-3 and schedule4 are conflict serializable

or not.

Solution:

(1) Clearly schedule-1 and schedule-2 are serial schedules, therefore these schedules are conflict

serializable
By Ajai Kumar Maurya CSE Mob: 9335833415
 •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.

By Ajai Kumar Maurya CSE Mob: 9335833415

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

By Ajai Kumar Maurya CSE Mob: 9335833415

Precedence graph for schedule S1:

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

why Schedule S1 is non-serializable.

By Ajai Kumar Maurya CSE Mob: 9335833415

By Ajai Kumar Maurya CSE Mob: 9335833415
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

By Ajai Kumar Maurya CSE Mob: 9335833415

Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why ScheduleS2 is serializable.

By Ajai Kumar Maurya CSE Mob: 9335833415

Conflict Serializable Schedule
• A schedule is called conflict serializability if after swapping of non-conflicting operations, it
can transform into a serial schedule.
• The schedule will be a conflict serializable if it is conflict equivalent to a serial schedule.
Conflicting Operations
The two operations become conflicting if all conditions satisfy:
1. Both belong to separate transactions.
2. They have the same data item.
3. They contain at least one write operation.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Example:
Swapping is possible only if S1 and S2 are logically eqal

Here, S1 = S2. That means it is non-conflict.

Here, S1 ≠ S2. That means it is conflict.

By Ajai Kumar Maurya CSE Mob: 9335833415

Conflict Equivalent
In the conflict equivalent, one can be transformed to
another by swapping non-conflicting operations. In the
Example
given example, S2 is conflict equivalent to S1 (S1 can be
converted to S2 by swapping non-conflicting
operations).
Two schedules are said to be conflict equivalent if and
only if:
1.They contain the same set of the transaction.
2.If each pair of conflict operations are ordered in the
same way.

By Ajai Kumar Maurya CSE Mob: 9335833415

Conflict Equivalent Cont..
Schedule S2 is a serial schedule because, in this, all operations
of T1 are performed before starting any operation of T2.
Schedule S1 can be transformed into a serial schedule by
swapping non-conflicting operations of S1.

After swapping of non-conflict operations, the schedule S1

becomes:

T1 T2

Read(A)
Write(A)
Read(B)
Write(B)
Read(A)
Write(A)
Read(B)
Write(B) Since, S1 is conflict serializable.

By Ajai Kumar Maurya CSE Mob: 9335833415

 View Serializability

By Ajai Kumar Maurya CSE Mob: 9335833415

View Serializability
• A schedule will view serializable if it is view equivalent
to a serial schedule.
• If a schedule is conflict serializable, then it will be view
serializable.
• The view serializable which does not conflict
serializable contains blind writes.

View Equivalent
Two schedules S1 and S2 are said to be view equivalent if they
satisfy the following conditions:

1. Initial Read Above two schedules are view equivalent because

Initial read operation in S1 is done by T1 and in S2 it is
An initial read of both schedules must be the same. Suppose also done by T1.
two schedule S1 and S2. In schedule S1, if a transaction T1 is
reading the data item A, then in S2, transaction T1 should also
read A.
By Ajai Kumar Maurya CSE Mob: 9335833415
View Serializability Cont..
2. Updated Read
In schedule S1, if Ti is reading A which is updated by Tj then in
S2 also, Ti should read A which is updated by Tj.

Above two schedules are not view equal because, in S1, T3 is reading A updated by T2
and in S2, T3 is reading A updated by T1.

By Ajai Kumar Maurya CSE Mob: 9335833415

View Serializability Cont..
3. Final Write
A final write must be the same between both the schedules. In
schedule S1, if a transaction T1 updates A at last then in S2,
final writes operations should also be done by T1.

Above two schedules is view equal because Final write

operation in S1 is done by T3 and in S2, the final write
operation is also done by T3.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Recoverability

By Ajai Kumar Maurya CSE Mob: 9335833415

 Recoverability of Schedule
Sometimes a transaction may not execute completely due to a software issue, system crash or hardware
failure. In that case, the failed transaction has to be rollback. But some other transaction may also have
used value produced by the failed transaction. So we also have to rollback those transactions

By Ajai Kumar Maurya CSE Mob: 9335833415

The above table 1 shows a schedule which has two transactions. T1 reads and writes the value of A

and that value is read and written by T2. T2 commits but later on, T1 fails. Due to the failure, we

have to rollback T1. T2 should also be rollback because it reads the value written by T1, but T2 can't

be rollback because it already committed. So this type of schedule is known as irrecoverable

schedule.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Irrecoverable schedule: The schedule will be irrecoverable if Tj reads the updated value of Ti and Tj
committed before Ti commit.

The above table 2 shows a schedule with two transactions. Transaction T1 reads and writes A, and that value is
read and written by transaction T2. But later on, T1 fails. Due to this, we have to rollback T1. T2 should be
rollback because T2 has read the value written by T1. As it has not committed before T1 commits so we can
rollback transaction T2 as well. So it is recoverable with cascade rollback.

By Ajai Kumar Maurya CSE Mob: 9335833415

Recoverable with cascading rollback: The schedule will be recoverable with cascading rollback if Tj reads the
updated value of Ti. Commit of Tj is delayed till commit of Ti

The above Table 3 shows a schedule with two transactions. Transaction T1 reads and write A and
commits, and that value is read and written by T2. So this is a cascade less recoverable schedule.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Recovery from Transaction

Failure

By Ajai Kumar Maurya CSE Mob: 9335833415

 To find that where the problem has occurred, we generalize a failure into the following categories:
1.Transaction failure
2.System crash
3.Disk failure
1. Transaction failure
The transaction failure occurs when it fails to execute or when it reaches a point from where it can't
go any further. If a few transaction or process is hurt, then this is called as transaction failure.
Reasons for a transaction failure could be -
1. Logical errors: If a transaction cannot complete due to some code error or an internal error
condition, then the logical error occurs.
2. Syntax error: It occurs where the DBMS itself terminates an active transaction because the
database system is not able to execute it. For example, The system aborts an active
transaction, in case of deadlock or resource unavailability.

By Ajai Kumar Maurya CSE Mob: 9335833415

 2. System Crash
• System failure can occur due to power failure or other hardware or software
failure. Example: Operating system error.
• Fail-stop assumption: In the system crash, non-volatile storage is assumed not to be
corrupted.
3. Disk Failure
• It occurs where hard-disk drives or storage drives used to fail frequently. It was a common
problem in the early days of technology evolution.
• Disk failure occurs due to the formation of bad sectors, disk head crash, and
unreachability to the disk or any other failure, which destroy all or part of disk storage.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Log-Based Recovery

By Ajai Kumar Maurya CSE Mob: 9335833415

 •The log is a sequence of records. Log of each transaction is maintained in some stable storage so that
if any failure occurs, then it can be recovered from there.
•If any operation is performed on the database, then it will be recorded in the log.
•But the process of storing the logs should be done before the actual transaction is applied in the
database.
Let's assume there is a transaction to modify the City of a student. The following logs are written for
this transaction.
•When the transaction is initiated, then it writes 'start' log.
1.<Tn, Start>
•When the transaction modifies the City from 'Noida' to 'Bangalore', then another log is written to the
file.
1.<Tn, City, 'Noida', 'Bangalore' >
•When the transaction is finished, then it writes another log to indicate the end of the transaction.
1.<Tn, Commit>
By Ajai Kumar Maurya CSE Mob: 9335833415
 There are two approaches to modify the database:
1. Deferred database modification:
•The deferred modification technique occurs if the transaction does not modify the
database until it has committed.
•In this method, all the logs are created and stored in the stable storage, and the
database is updated when a transaction commits.
2. Immediate database modification:
•The Immediate modification technique occurs if database modification occurs while
the transaction is still active.
•In this technique, the database is modified immediately after every operation. It
follows an actual database modification.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Recovery using Log records
When the system is crashed, then the system consults the log to find which transactions
need to be undone and which need to be redone.
1.If the log contains the record <Ti, Start> and <Ti, Commit> or <Ti, Commit>, then the
Transaction Ti needs to be redone.
2.If log contains record<Tn, Start> but does not contain the record either <Ti, commit> or
<Ti, abort>, then the Transaction Ti needs to be undone.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Checkpoints

By Ajai Kumar Maurya CSE Mob: 9335833415

 • The checkpoint is a type of mechanism where all the previous logs are removed
from the system and permanently stored in the storage disk.
• The checkpoint is like a bookmark. While the execution of the transaction, such
checkpoints are marked, and the transaction is executed then using the steps of the
transaction, the log files will be created.
• When it reaches to the checkpoint, then the transaction will be updated into the
database, and till that point, the entire log file will be removed from the file. Then
the log file is updated with the new step of transaction till next checkpoint and so
on.
• The checkpoint is used to declare a point before which the DBMS was in the
consistent state, and all transactions were committed.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Recovery using Checkpoint
In the following manner, a recovery system recovers the database from this failure:

By Ajai Kumar Maurya CSE Mob: 9335833415

 •The recovery system reads log files from the end to start. It reads log files from T4 to T1.
•Recovery system maintains two lists, a redo-list, and an undo-list.
•The transaction is put into redo state if the recovery system sees a log with <Tn, Start> and
<Tn, Commit> or just <Tn, Commit>. In the redo-list and their previous list, all the transactions
are removed and then redone before saving their logs.
•For example: In the log file, transaction T2 and T3 will have <Tn, Start> and <Tn, Commit>. The
T1 transaction will have only <Tn, commit> in the log file. That's why the transaction is
committed after the checkpoint is crossed. Hence it puts T1, T2 and T3 transaction into redo
list.
•The transaction is put into undo state if the recovery system sees a log with <Tn, Start> but no
commit or abort log found. In the undo-list, all the transactions are undone, and their logs are
removed.
•For example: Transaction T4 will have <Tn, Start>. So T4 will be put into undo list since this
transaction is not yet complete and failed amid.
By Ajai Kumar Maurya CSE Mob: 9335833415
 Deadlock

By Ajai Kumar Maurya CSE Mob: 9335833415

 A deadlock is a condition where 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 no task ever gets finished and is in waiting state forever.

For example: In the student table, transaction T1 holds a lock on some rows and needs

to update some rows in the grade table. Simultaneously, transaction T2 holds locks on

some rows in the grade table and needs to update the rows in the Student table held

by Transaction T1.

By Ajai Kumar Maurya CSE Mob: 9335833415

 Now, the main problem arises. Now Transaction T1 is waiting for T2 to release its lock and
similarly, transaction T2 is waiting for T1 to release its lock. All activities come to a halt state and
remain at a standstill. It will remain in a standstill until the DBMS detects the deadlock and
aborts one of the transactions

By Ajai Kumar Maurya CSE Mob: 9335833415

Deadlock Avoidance

• When a database is stuck in a deadlock state, then it is better to avoid the database rather than
aborting or restating the database. This is a waste of time and resource.
• Deadlock avoidance mechanism is used to detect any deadlock situation in advance. A method
like "wait for graph" is used for detecting the deadlock situation but this method is suitable only
for the smaller database. For the larger database, deadlock prevention method can be used.

Deadlock Detection
In a database, when a transaction waits indefinitely to obtain a lock, then the DBMS should detect whether the
transaction is involved in a deadlock or not. The lock manager maintains a Wait for the graph to detect the
deadlock cycle in the database.

By Ajai Kumar Maurya CSE Mob: 9335833415

 AKTU PREVIOUS YEAR QUESTION
1. What do you mean by Conflict Serializable Schedule?
2. What do you understand by ACID properties of transaction ? Explain in details.
3. Define Transaction and explain its properties with suitable example.
4. What is schedule? What are its types? Explain view serializable and cascadeless schedule
with suitable example of each.
5. Which of the following schedules are conflicts serializable? For each serializable schedule find
the equivalent serial schedule. S1: r1(x);r3(x);w3(x);w1(x);r2(x) S2:
r3(x);r2(x);w3(x);r1(x);w1(x) S3: r1(x);r2(x);r3(y);w1(x);r2(z);r2(y);w2(y) 8 Transaction
6. Explain I in ACID Property.
7. Define schedule.

By Ajai Kumar Maurya CSE Mob: 9335833415

 AKTU PREVIOUS YEAR QUESTION
8. What do you mean by serializability? Discuss the conflict and view serialzability with
example. Discuss the testing of serializability also.
9. What do you mean by Transaction? Explain transaction property with detail and suitable
example.
10. What is serializability? How it is tested?
11. State the properties of transaction.
12. What is transaction? Draw a state diagram of a transaction showing its state. Explain ACID
properties of a transaction with suitable examples.
13. What are the schedules? What are the differences between conflict serialzability and view
serialzability ? Explain with suitable examples what are cascadeless and recoverable
schedules? 9 Transaction Thank

By Ajai Kumar Maurya CSE Mob: 9335833415