Scribd
Upload
18 views18 pages

19 - Transaction Management Part 2

Uploaded by

Bhavya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODP, PDF, TXT or read online on Scribd
18 views18 pages

19 - Transaction Management Part 2

Uploaded by

Bhavya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as ODP, PDF, TXT or read online on Scribd
You are on page 1/ 18

Transaction Management

Part 2
Serializability
In a database system, we can have number of
transaction processing. Related transactions will be
processed one after another. There are some transactions
processes in parallel. Some of the transactions can be
grouped together.
A schedule is a process of grouping the transactions
into one and executing them in a predefined order. A
schedule is required in a database because when some
transactions execute in parallel, they may affect the
result of the transaction - means if one transaction is
updating the values which the other transaction is
accessing, then the order of these two transactions will
change the result of second transaction. Hence a
schedule is created to execute the transactions.
A schedule is called serial schedule, if the transactions
in the schedule are defined to execute one after the other.
Even when we are scheduling the
transactions, we can have two transactions
in parallel, if they are independent. But if
they are dependent, then the results will
change.
For example, say one transaction is
updating the marks of a student in one
subject; meanwhile another transaction is
calculating the total marks of a same
student.
If the second transaction is executed
after first transaction is complete, then
both the transaction will be correct.
But what if second transaction runs
first? It will have wrong total mark.
This type of incorrect processing of transaction
needs to be handled in the system. Parallel
execution of transaction is allowed in the
database only if there is any equivalence
relation among the transactions.

78 222
There are three types of equivalence
relation among the transactions – Result,
View and Conflict Equivalence.
Result Equivalence: - If the two
transactions generate same result after their
execution then it is called as result
equivalence.
For example, one transaction is updating
the marks of Student X and the other
transaction is to insert a new student. Here
both the transactions are totally independent
and their order of execution does not matter.
Whichever order they are executed; the result
is the same. Hence it is called result
equivalence transactions.
View Equivalence: -Two schedules are
said to be view equivalence, if the transaction
in one schedule is same as the one in other.
That means, both the transactions in two
schedules perform same tasks.

For example, say schedule1 has transaction


to insert new students into STUDENT table
and second schedule has the transaction to
maintain the old student records in a new
table called OLD_STUDENT. In both the
schedules student details are inserted, but
different tables (it does not matter if it is
same table). Such schedules are called as
view equivalence schedule.
Conflict Equivalence: - In this case
both schedules will have different set
of transactions, but they would be
accessing same data and one of the
schedules will be inserting/updating the
records. In this equivalence, both the
schedules will have conflicting set of
transactions. In example of updating the
marks of one student by one transaction
and calculating the total marks at the same
time is a conflicting equivalence.

In all these cases if the transaction


is serialized, then the issues can be
resolved.
Concurrency Control
When there are multiple transactions
executing at the same time on same data, it may
affect the result of the transaction. Hence it is
necessary to maintain the order of execution of
those transactions.

In addition, it should not alter the ACID


property of a transaction.

In order to maintain the concurrent access of


transactions, some protocols are introduced.
Concurrency Control
Lock Based Protocol: - A lock is a mechanism
to control concurrent access to a data item. Lock is
in other words called as access.
A locking protocol is a set of rules followed by
all transactions while requesting and releasing locks.

In this type of protocol any transaction will not


be processed until the transaction gets the lock on
the record.
That means any transaction will not retrieve or
insert or update or delete the data unless it gets the
access to that particular data.
These locks are broadly classified as Binary locks and
shared / exclusive locks.
In binary lock data can either be locked or unlocked. It
will have only these two states. It can be locked for retrieve or
insert or update or delete the data or unlocked for not using
the data.
Exclusive lock (X) mode. Data item can be both read as
well as written. X-lock is requested using lock-X instruction.
In this technique the data is said to be exclusively locked for
insert / update /delete. When it is exclusively locked no other
transaction can read or write the data.

Shared (S) mode. Data item can only be read. S-lock is


requested using lock-S instruction. When a data is read
from the database, then its lock is shared i.e.; the data can be
read by other transaction too but it cannot be changed while
retrieving the data.
Simplistic Lock Protocol: -As the name suggests it is the
simplest way of locking the data during the transaction. This
protocol allows all the transaction to get the lock on the data
before insert / update /delete on it. After completing the
transaction, it will unlock the data.

Pre-claiming Protocol: - In this protocol, it evaluates the


transaction to list all the data items on which transaction
needs lock. It then requests DBMS for the lock on all those
data items before the transaction begins. If DBMS gives the
lock on all this data, then this protocol allows the transaction
to begin. Once the transaction is complete, it releases all the
locks.
For example, if we have to calculate total marks of 3
subjects, then this protocol will evaluate the transaction and
list the locks on subject1 marks, subject2 marks and then
subject3 marks. Once it gets all the locks, it will start the
transaction.
Lock-Based Protocols (Cont.)

Example of a transaction performing


locking:

T2: lock-S(A);
read (A);
unlock(A);

lock-S(B);
read (B);
unlock(B);
display(A+B)
Two Phase Locking Protocol (2PL): - In this type of protocol, as the
transaction begins to execute, it starts requesting for the locks that it
needs. It goes on requesting for the locks as and when it is needed. Hence
it has a growing phase of locks. At one stage it will have all the locks.
Once the transaction is complete it goes on releasing the locks. Hence it
will have descending phase of locks. Thus this protocol has two phases:
Phase1: Growing phase of locks,
Phase 2: Shrinking phase of locks.
For example, if we have to calculate total marks of 3
subjects, then this protocol will go on asking for the locks
on subject1 marks, subject2 marks and then subject3
marks.

As and when it gets the locks on the subject marks it


reads the marks. It does not wait till all the locks are
received. Then it will have total calculation.

Once it is complete it release the lock on subject3


marks, subject2 marks and subject1 marks.
Strict Two Phase Locking (Strict 2PL): - This protocol is similar
to 2PL in the first phase. Once it receives the lock on the data, it
completes the transaction. Here it does not release the locks as it is
used and no more required. It waits till whole transaction to
complete and commit, then it releases all the locks at a time. This
protocol hence does not have shrinking phase of lock release.

In the example of calculating total marks of 3 subjects, locks


are achieved at growing phase of the transaction and once it
receives all the locks, it executes the transaction. Once the
transaction is fully complete, it releases all the locks together.
Time Stamp Based Protocol: - In this method, as soon
as a transaction is created it assigns the order of the
transaction. The order of the transaction is nothing but the
ascending order of the transaction creation.
The priority for older transaction is given to execute
first. This protocol uses system time or logical counter to
determine the time stamp of the transaction.
Suppose there are two transactions T1 and T2. Suppose
T1 has entered the system at time 0005 and T2 has entered
the system at 0008 clock time. Priority will be given to T1
to execute first as it is entered the system first.
In addition to the timestamp of a transaction, this
protocol also maintains the timestamp of last ‘read’ and
‘write’ operation on a data. Based on the timestamp of
transaction and the data which it is accessing a timestamp
ordering protocol is defined.
END

You might also like