DR.

APJ ABDUL KALAM TECHNICAL UNIVERSITY

Branch - CSE
Database Management System
UNIT - IV, Lecture – 1

Transaction System, Testing of Serializability,

Serializability of Schedules
By

Dr. Kakoli Banerjee

Associate Professor
Department of Computer Science & Engineering
JSS Academy of Technical Education, Noida
Transaction
A transaction is a unit of program execution that accesses and
possibly updates various data items.
E.g. transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
Transaction cont..
Two main issues to deal with:

• Failures of various kinds, such as hardware failures and

system crashes

• Concurrent execution of multiple transactions

Transaction cont..
ACID Properties of a Transaction
Atomicity - Either all operations of the transaction are properly reflected in
the database or none are.
Consistency - Execution of a transaction in isolation preserves the
consistency of the database.
Isolation - Although multiple transactions may execute concurrently, each
transaction must be unaware of other concurrently executing transactions.
Intermediate transaction results must be hidden from other concurrently
executed transactions.
That is, for every pair of transactions Ti and Tj, it appears to Ti that either
Tj, finished execution before Ti started, or Tj started execution after Ti
finished.
Durability - After a transaction completes successfully, the changes it has
made to the database persist, even if there are system failures.
 ACID Properties
A transaction is a unit of program execution that accesses and possibly updates
various data items. To preserve the integrity of data the database system must ensure:
• Atomicity. Either all operations of the transaction are properly reflected in the
database or none are.
• Consistency. Execution of a transaction in isolation preserves the consistency of the
database.
• Isolation. Although multiple transactions may execute concurrently, each transaction
must be unaware of other concurrently executing transactions. Intermediate
transaction results must be hidden from other concurrently executed transactions.
– That is, for every pair of transactions Ti and Tj, it appears to Ti that either Tj,
finished execution before Ti started, or Tj started execution after Ti finished.
• Durability. After a transaction completes successfully, the changes it has made to the
database persist, even if there are system failures.
Transaction cont..
States of a Transaction
States of a Transaction
Active When a transaction is fired (starts execution), it enters Active State. The
transaction remains in this state during its entire execution.
Partially Committed A transaction enters this state when its last statement has been
executed, but its update are not yet made safe.
Committed A Partially-Committed transaction enters COMMITTED state,
when all its updates have been made safe by the DBMS; either in the database
itself or in a Log File (both on a non-volatile media)
Failed A transaction enters this state when it is not able to proceed in a
normal manner, either due to its own internal error or due to some system
failure (hardware failure or software failure).
Aborted A Transaction T enters Aborted State, when it has been rolled-back
after a failure. This is the state when the failed Transaction T has reverted
back to the initial state, which existed prior to its commencement. The end
result is as though T had never commenced execution.
Terminated A Transaction is said to be terminated, when it has either
committed successfully or has aborted after a failure.
Transaction cont..
Advantages offered by the Concurrent execution of transactions

Improved system throughput and Resource Utilization When an

executing Transaction Ti requests I/O it goes to ‘wait’ state till its I/O
is completed. During this period, the CPU is free and another ready
transaction is assigned to the CPU.
Reduced average waiting time of transactions
At any moment, there will be a mix of transactions of varying lengths.
In concurrent processing, the relatively shorter transactions would get
completed during I/O bursts of longer transactions; and thus reducing
the average waiting time of the transactions considerably.
Concurrency Control
The exploitation of concurrency amongst transactions throws up
the issue of concurrency control. This control has to be
exercised by the DBMS to ensure that the execution of the
concurrent transactions is dovetailed in such a manner that the
concurrent execution is virtually equivalent to serial execution.
So, the system is able to draw benefits of concurrency while
preserving database consistency at the same time.
Execution Schedule of Transactions
A Schedule refers to the chronological order, in which instructions of
concurrent transactions are executed by the system.

Serial Schedule

A serial schedule is the one, in which transactions are executed, strictly

one after another. The execution of next transaction is taken up, only
after the successful completion of the previous transaction.
Example
Suppose the initial balance of accounts is A= 5000 and B =3000

T1: Transfer Rs 1000 from Account A to B

T2: Credit Rs 500 to Account A
Execution Schedule of Transactions
Serial Schedule
Example
Execution Schedule of Transactions
Serial Schedule
Example
Execution Schedule of Transactions
Serial Schedule

The Schedules S1 & S2 execute the transactions T1 and T2 serially i.e. T1 followed by
T2 in Schedule S1 and T2 followed by T1 in Schedule S2. Such Schedules are called
serial schedules. Execution of Serial Schedules would preserve consistency of the
database; without requiring any additional mechanism. But, such schedules do not
exploit the potential parallelism amongst the transactions.

Concurrent Schedules

When more than one Transaction are taken up for execution at the same time (concurrently),
the system would schedule one of the concurrent transactions (say Ti) to take control of the
CPU. During the execution, when Ti request I/O, then Ti would go to a ‘wait’ state, waiting for
completion of its I/O. since, the CPU would now be free, the system would schedule another
concurrent transaction (say Tj) that may be ready to take control of CPU.
Execution Schedule of Transactions
Concurrent Schedules
Execution Schedule of Transactions
Concurrent Schedules
Execution Schedule of Transactions
Equivalent Schedules
Two Schedules S and S’ are said to be Equivalent, if when
executed independently, each of the schedules transforms the
affected database from a consistent state S1 to another
consistent state S2.

Serializable Schedules
Suppose S is a Concurrent Schedule and there exists a
Schedule S’, which is serial and logically equivalent to S,
then S is said to be a Serializable Schedule.
THANK YOU
Serialization
If left entirely to the Operating System, to decide on the interleaving
of the concurrent transactions, it would not be possible to predict the
end results and the database may be left in an inconsistent state. So, it
is to be ensured by the DBMS that any schedule that executes, must
leave the database in a consistent state. The database component that
ensures this aspect is called concurrency-control-component. The
schedule should in some sense be equivalent to a serial schedule.
This process is called serialization.
Types of Serializability
Types of Serializability The serializability of schedules is of two types:-
• Conflict Serializability
• View Serializability

Conflict Serializability

This is based on the concept of logical swapping of non-conflicting instructions in a

schedule.
Types of Serializability
Non-Conflicting Instructions
Let a Schedule S have two consecutive instructions Ii and Ij belonging to
two concurrent Transactions Ti and Tj respectively such that Ii ∈ Ti and Ij ∈
Tj.
The two consecutive instructions would be called non-conflicting, if they
satisfy any of the following conditions:-
• The instructions are referring to the access of different data items. For
example Ii may be referring to the access of data item P and Ij may be
referring to access of another data item Q.
• Both are referring to the access of the same data item (say Q) and both
are only Read instructions.
• If the non-conflicting instructions are swapped on the time-scale, the end
state of the database remains unchanged. So, logical swapping of two
non-conflicting instructions makes no difference as far as database
consistency is concerned.
Types of Serializability
Conflicting Instructions
On the other hand, two consecutive instructions Ii and Ij, belonging to two
concurrent Transactions Ti and Tj respectively such that Ii ∈ Ti and Ij ∈ Tj,
are called conflicting instructions if both are referring to the access of same
data item (say Q) and at least one of the two instructions is a Write (Q)
instruction. In this case, changing the order of the two instructions would
effect the end-results of database updates.
Conflict-Equivalence of Schedules
Two schedules S and S’ are said to be Conflict-Equivalent, if by a series of SWAPS of non-conflicting
instructions of S, the schedule S gets transformed to Schedule S’. For example Schedule S 5 and
Schedule S6 are Conflict-Equivalent Schedules.

Conflict Serializable Schedule

A Concurrent (Non-Serial) Schedule S is said to be Conflict-Serializable, if there exists a serial

schedule S’ that may be Conflict-Equivalent to S.
Conflict-Equivalence of Schedules
Conflict-Equivalence of Schedules
Conflict-Equivalence of Schedules
Testing of Serializability of a Schedule
We can test the conflict-serializability of a concurrent schedule by using Precedence Graph
Method, explained below:-
View Serializability
In some situations, a schedule S may not be conflict-serializable; but it may be equivalent
to a serial schedule S’, which starting from a given initial state of a database, produces
same end-results in the database as produced by S starting from the same initial state. For
example consider Schedule S8:-
View Serializability
View Serializability
View Equivalence A Schedule S is said to be View Equivalent to another Schedule S’, if the following
conditions are met:-
• For each data item Q, if transaction Ti reads its initial value of Q in S, then Ti must be reading the
initial value of Q in S’ also.
• For each data item Q, if a transaction Tj writes out its final value in S, it must be similar in S’ also.
• For each data item Q, if transaction Tj reads the value of Q produced by other transaction Ti in S,
then it must be similar in S’ also.

A conflict-serializable schedule will also be view-serializable, but reverse may not be true.
Cascading Rollbacks
Suppose a Transaction Ti modifies a data item Q and the modified value of Q is read by another
Transaction Tj before transaction Ti COMMITS. Now, suppose Ti fails during its execution and it has to
be rolled-back. So, the value of data item Q, which Tj has read is undone by the rolling-back of Ti.
Thus, any computation performed by Tj , based on this value of Q, would cause database
inconsistencies. Thus, when transaction Ti fails during its execution, and it has to be rolled back, we
also have to rollback those transactions, which might have read the data items modified by Transaction
Ti. Such a Rollback is called a Cascading Rollback.
Cascading Rollbacks
In the Schedule S10, Since T2 reads the value of data item A, after
it has been already modified by T1, but before T1 commits and also
T3 reads the value of data item A as modified further by T2 but
before T1 commits and T2 commits. In this case, if T1 fails during
its subsequent execution before it Commits, then T2 and T3 also
must rollback along with T1. This kind of rollback is called
Cascading Rollback.
Cascade-less Schedules
The need of Cascading Rollbacks can be effectively obviated by imposing a restriction on the
schedules that the data items, modified by a Transaction Ti, must not be permitted to be read by other
concurrent transactions, till Ti Commits. Such Schedules are called Cascade-less Schedules. The
Cascade-less Schedules obviate the need of Cascading Rollbacks.

Recoverable Schedules

A concurrent Schedule is said to be Recoverable, iff:-

It is Serializable (Conflict-Serializable or View-Serializable)

AND
It is a Cascade-less.
THANK YOU
 DR. APJ ABDUL KALAM TECHNICAL UNIVERSITY

Branch - CSE
Database Management System
UNIT - IV, Lecture – 3

Log Based Recovery, Checkpoints, Deadlock

Handling
By

Dr. Kakoli Banerjee

Associate Professor
Department of Computer Science & Engineering
JSS Academy of Technical Education, Noida
Recovery
A failure would leave the Database System in a Suspect State. Recovery implies
restoring the Database (after a failure) to a state that is assumed to be Consistent.
The Recovery is made possible by the log of updates maintained in a system Log-File
on a stable (non-volatile) storage.

Let us consider a Transaction for Transfer an amount of Rs.1000/= from

ACCOUNT# 100 to ACCOUNT# 200.

Let the relation Account be on Schema ACCOUNT (Account-No, Branch-Name, Bal).

BEGIN TRANSACTION;
UPDATE Account
SET Balance = Balance –1000
WHERE Account-No = ‘100’;
UPDATE Account
Balance = Balance + 1000
WHERE Account-No = ‘200’;
COMMIT ;
Recovery
The above transaction involves two updates to the relation Account. Temporarily, the
database would be in an inconsistent state, when one update has been performed and the
other one is still to be performed. During this period, the total Balance at the BRANCH
would be deficit by 1000, but at the end of the Transaction, the total would tally. So, we can
state that a Transaction transforms database from one consistent state to other
consistent state, without necessarily preserving consistency at all intermediate steps.
Suppose the system fails between the two updates i.e. the first update
is executed, but not the second. Then, the database would be left in an
inconsistent state. To obviate this situation, the Transaction should be
either executed in its entirety or not at all. So, if a transaction
executes some of its updates and then a failure occurs before the
transaction reaches its planned termination, then the completed
updates must be undone (called ROLLBACK). The system
component that provides this atomicity to the transaction processing is
called Transaction Manager.
Type of Transactions
• COMMIT TRANSACTION This operation signals a successful end of the
Transaction.
• ROLLBACK TRANSACTION This operation signals an unsuccessful end of the
transaction.

The log is maintained in two portions:-

• An active or online log, which is maintained on the online disk. This log is used for
minor recoveries, during normal operations.
• An archive or offline log, which is maintained on a tape. The offline log maintains the
record of updates since the last backup, which are used to restore the system, in case of
major failures.
Recovery
Transaction Recovery A transaction begins with the successful execution of a
BEGIN TRANSACTION statement and ends with the successful execution of a
COMMIT or ROLLBACK statement. Thus, a COMMIT establishes a COMMIT
POINT at which database is in a state of consistency. A ROLLBACK rolls back
the database to the previous COMMIT POINT, at which again the database was in
a state of consistency.

When a COMMIT POINT is established:-

1. All the updates, made by the program since the previous COMMIT POINT, are
committed i.e. are made PERMANENT.
2. All database pointers (i.e. addressability to certain tuples) and all tuple- locks
will be released.
System Recovery
There are two types of System Failures:-

A local failure affects only the transaction, during the execution of which the
failure has occurred.

A global failure affects all the transactions that may be in progress at the time of
failure. Such failure fall into two broad categories:-

1. System Failure (e.g. Power Failure) This affects all transactions currently in
progress but does not physically damage the database. This failure is called soft
crash.

2. Media Failure (e.g. Disk Head Crash) It causes damage to the database, or to
some portion of it, and affects those transactions currently using that portion of
the database. A media failure is called hard crash.
Modes of Database Updates
Immediate Update
When an active Transaction Ti updates a data item Q, the update is immediately
reflected in the database (on stable storage) even before Ti Commits. In this case,
there will be a requirement to UNDO the updates of those transactions, which fail
before Commit Point is reached. Another limitation of this mode of update is that
for each update, the system has to perform a Disk-Write, that too on sectors which
may be widely separated. This involves significant overheads of Disk Seek Time.

How to UNDO the updates in case of ROLLBACK?

The System maintains a log (or journal) of all operations on the disk, which
contains details of all updates. The pre-update and post-update values of the
updated objects are recorded in the log, as follows:-
This implies that Transaction Ti has updated data item Q from Old-Value to New-
Value.
<Ti , Q, Old-Value, New-Value>
Recovery from System Failures.
During System Failures, contents of the main memory i.e. database buffers are
lost. The precise state of the transactions, which were in progress at the time of
failure, will no longer be known. Such transactions would need to be rolled back,
when the system is restarted after the failure.

There may be some transactions, which might have already committed prior to the
system failure, but not managed to get their updates transferred from the database
buffers to the physical database. Such transactions will need to be redone.
Recovery from System Failures.
Which failed transactions to be UNDONE and which transactions to be
REDONE?

During the normal operations, the system keeps TAKING CHECKPOINTS at

pre-specified regular intervals or when prescribed number of entries have been
made in the log. Taking a CHECKPOINT means:-

1. Physically writing (force-writing) the contents of the database buffers into the
physical database.

2. Physically writing a special CHECKPOINT RECORD into the physical non-

volatile log. This CHECKPOINT RECORD gives a list of the transactions that
were in progress at the time of taking the CHECKPOINT .
 Deadlock Handling in Transaction Processing
Deadlock in Transaction Processing
It refers to a situation wherein Transactions Wait forever for accessing the Data Items
locked by each other.

Necessary Conditions for Deadlock to Occur

There are four conditions, which must exist simultaneously, for a Deadlock to Occur:-
(1) Mutual Exclusion Some Data Items must be locked by some transactions in Exclusive
Mode.
(2) Hold & Wait Some Transactions must be holding Exclusive Locks on some Data Items
and at the same time must be requesting Exclusive Lock on some other data items currently
locked by other transactions.
(3) No Pre-emption The data items locked exclusively by a Transaction can not be forcibly
pre-empted. The Transaction will release the locks at its own will.
(4) Cyclic Wait The must exist a situation, wherein a set of n transactions say (T0, T1 , T2,
…… , Tn-1) are waiting in a cyclic manner for the data items locked by each other.
Deadlock Prevention
The Deadlocks can be prevented by imposing some restrictions on the sequence,
in which a given set of data items, can be accessed by a Transaction. One such
algorithm is explained below, which is graph based.

Graph Based Algorithm to Lock Resources

It works as follows:-
- A graph is drawn in which each node represents a Data Item
- A node will have only one parent.
- A transaction can Lock Data Items as follows:-
• First Lock can be obtained on any Node
• Any Subsequent lock can be obtained only on a Node whose parent is
currently locked by the Transaction.
• Lock on Root Node can be obtained only as a first lock; it cannot be locked
subsequently.
• If a Transaction violates the above protocol, it is forced to Roll-back.
Deadlock Prevention
Suppose, the Resource Graph for some environment is as follows:-
Suppose a Transaction Ti needs to access data items F,
E, B in that order, it has to obtain locks in the
following sequence

Lock-X (A);
Lock-X (C);
Lock-X (F);
Access (F);
Unlock (F);
Unlock (C);
Lock-X (B);
Lock-X (E);
Access( E);
Unlock (E);
Access (B);
Unlock (B);
Unlock (A);
Deadlock Detection & Recovery
Deadlock Recovery will involve Roll-back of some of the
transactions involved in the Deadlock; but before that a
deadlock needs to be detected.

Deadlock Detection

Transaction Wait For Graph Method

- A Directed Edge Graph is drawn, wherein each node
represents a Transaction.
- A directed edge from Ti to Tj indicates that Ti is waiting for
a data item currently locked by Tj.
- If there exists a cycle in the Graph, it indicates existence of
a Deadlock; else there is no Deadlock.
Deadlock Recovery
When a deadlock is detected, the system initiates recovery action, which involves roll-back
of some of the transactions involved in the Deadlock. The rolled-back transactions would
release the exclusive locks currently held by these transactions. So, the other transactions,
which may be waiting for such locks, would get the awaited resources and would proceed;
thus breaking the Deadlock.

The issues involved are:-

1. Selection of Victims for Roll-Back: The Criteria for selection of victim would take into
consideration:-
- The amount of work already completed by the transaction. Since this work will be undone during
the roll-back, so a transaction which has completed lesser work should be a preferred as a victim.
- The amount of work yet to be completed. This information is difficult to get. However, if this
information is available, then the transaction, which is still farther from the end, should be preferred as a
victim. A Transaction, which is near its end, should not be rolled-back.
- The Number of resources locked by the Transaction . If a transaction with large number of
resources locked by it is rolled back, then large number of resources will get free, which may meet the
need of large number of waiting transaction.
Deadlock Recovery
2. Roll Back the selected Transaction. With the help of log file entries, the data items
modified by this transaction will be reverted back to their old values. Also, the data items,
currently locked by this transaction, will be unlocked. So, the other transactions, awaiting
lock on such data items, will be able to proceed and the deadlock will be broken.

3. Restart the Rolled-Back Transaction. Once the deadlock is broken, the rolled-back
transaction is restarted.

Implications of Deadlock Recovery

1. The work already performed by the rolled-back transaction is undone. In fact, undoing
it also needs more work to be performed. So, system throughput gets affected
adversely.

2. There is always a possibility that a Transaction may face roll-back again and again and
may never get completed; thus facing starvation.
THANK YOU
 DR. APJ ABDUL KALAM TECHNICAL UNIVERSITY

Branch - CSE
Database Management System
UNIT - IV, Lecture – 4

Distributed Database: Distributed Data Storage

By

Dr. Kakoli Banerjee

Associate Professor
Department of Computer Science & Engineering
JSS Academy of Technical Education, Noida
Distributed Database Systems
A Distributed Database implies a database distributed over several inter-connected
computers, which may be:-

• Geographically dispersed
• Vary in size & function (may vary from workstation to mainframe)
• Separately administered
• Inter-connected by WAN/LAN using different communication media.

Node or Site

A computer, forming part of a Distributed Database System, is called a Node or a

Site.
A Distributed DBMS is characterized by the following:-
(a) Sharing of Data Users at one site may be able to access data residing at
other sites. For example, in case of banking database, it is possible to
transfer funds from an account maintained at one branch to another account
maintained at another branch.

(b) Autonomy There may be a Global Database Administrator, who may

be responsible for the entire system. In addition, there may be Local
Database Administrators of each site. The local administrator will retain
some degree of control over its own database.

(c ) Improved System Availability In the distributed systems, each data

item is replicated at multiple sites; so the failure of some sites will not
result in total system failure. A Global Transaction, needing certain data,
may find it at several sites, despite failure of some sites. When a failed site
recovers, its database is updated, before integrating it back into the System.
Data Replication
Advantages of Data Replication

• Higher availability of system. If one site containing a relation r fails, the

relation r may be found replicated at some other sites; thus the system
continues to process the queries related to relation r, despite failure of some
of the sites.
• Increased Parallelism. The Read operations on a relation can be processed
locally in parallel at the sites, where it is replicated. In this case, data
movement across the network is avoided.

Disadvantages of Data Replication

• Increased Overhead on Update The System has to ensure that all copies
of replicated data are kept updated, to ensure consistency of database.
During Write operations, it results in increased movement of data across the
network and increased processing overheads at the sites containing replica
of updated relations.
Data Fragmentation
Data Fragmentation implies dividing a Relation r into n Fragments r1,r2, … rn.
The fragments must contain sufficient information to allow reconstruction of
the original relation r from the fragments. There are two types of
fragmentation:-

(a) Horizontal Fragmentation. A relation r is partitioned into a number of

subsets (called fragments) such that each tuple of the fragmented relation
belongs to at least one of the fragments.

(b) Vertical Fragmentation. A Vertical Fragmentation implies:-

Partitioning of a schema R into n sub-schemas i.e. R1 , R2 , …….Rn such

that R = R1 U R2 U R3 U ….. U Rn
Distributed Transactions.
A transaction in a distributed environment may be getting executed at multiple
sites. So, commit of such transactions becomes a very complex issue. The
transactions in a Distributed Database environment may be classified as:-

(a) Local Transaction A transaction, which accesses only the database that is
stored at the local site i.e. the site where the transaction was initiated.

(b) Global Transaction A transaction, which accesses database at sites (may

be multiple sites) other than the site where the transaction was initiated, is
called Global Transaction.
System Structure for Distributed Transaction
Processing
An abstract model, for a distributed transaction processing environment, has a
Transaction Manager and a Transactions Coordinator with the broad functions
as follows:-

(a) Transaction Manager Each site will have a local Transaction Manager,
whose function will be to ensure ACID properties of those transactions (or
sub-transactions) that execute at that site. Various Transaction Managers
cooperate with each other, to execute the Global Transactions. It is responsible
for:-
• Maintaining a log, for recovery purposes.
• Participating in an appropriate concurrency-control scheme, to coordinate
the concurrent execution of transactions executing at that site.
System Structure for Distributed Transaction
Processing
(b) Transaction Coordinator It coordinates the execution of transactions
(both local and global) initiated at that site. For each such transaction, the
coordinator is responsible for:-

• Starting execution of a transaction.

• Dividing a transaction into a number of sub-transactions and distributing
these sub-transactions to the appropriate sites for execution.
• Coordinating the termination of the transaction, which may result in the
transaction being committed at all the participating sites or aborted at all
the sites.
System Structure for Distributed Transaction
Processing
System Failure Modes in a Distributed Databases environment

A distributed system will have all those failure modes, which occur in
centralized systems. In addition, it will have some failure modes, which are
typical only to distributed environment:-

• Failure of some of the participating Sites.

• Loss of messages between the Sites.
• Failure of Communication Links.
• Network Partitioning - A system is said to be partitioned, if due to some
failures, it gets split into two or more sub-networks (called partitions) not
connected to each other.
COMMIT PROTOCOLS
To ensure the property of atomicity, a distributed transaction should either
COMMIT at all the participating sites or it should ABORT at all the sites.

TWO-PHASE COMMIT (2PC) PROTOCOL

COMMIT PROTOCOLS
THREE-PHASE COMMIT (2PC) PROTOCOL
Locking Protocols
To access data items in a mutual exclusion manner, the transactions lock data
items to be accessed and then perform the access operations like read, write
etc. There are two types of locking protocols in a distributed environment:-

Single Centralized Lock Manager

The System maintains a single centralized lock manager, which resides in a

single chosen site – say Si. All lock and unlock requests are made to that site
Si. Whenever, a transaction needs to lock a data item, it sends a request for
lock to site Si. As a lock request is received at Si, the lock manger checks
whether the requested lock can be granted immediately, else the request is
queued. Whenever the request is granted, a message is sent to the originator of
the request.
Locking Protocols
After a request to access a data item is granted, the access will be as follows:-

- For Read, the data item can be read from any of the sites, where replica of
the data item exists.
- For Write, all replicas of the data item have to be updated.
For unlock, only a single message is required to be sent from the site releasing
a lock to the site Si.

Advantages:-
Simple implementation.
Simple deadlock handling, since all data items are centrally controlled.
Disadvantages:-
Site Si becomes a bottle-neck, since all requests have to be processed there.
Locking Protocols
(b) Distributed Lock Manager The lock manager function is distributed over
several sites. Each site administers the lock management of data items stored
at that site. Here, since the lock manager function is distributed over a large
number of sites, the approach is free of the limitations of a centralized
approach. However, deadlock handling is complex in this case.
THANK YOU