Scribd
Upload
87 views

Distributed Systems Assignment 6

Distributed concurrency control ensures that distributed transactions execute consistently across multiple data servers. It extends concurrency control techniques from centralized databases to account for dependencies across servers. There are three main approaches: locking, timestamp ordering, and optimistic concurrency control. Active replication involves all replicas processing requests identically to tolerate failures, while passive replication uses a primary server and backups to provide fault tolerance in a less computationally intensive manner. Distributed deadlocks can occur when transactions on different servers form a cyclic wait-for graph through their locking dependencies.

Uploaded by

sowmyalalitha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
87 views

Distributed Systems Assignment 6

Distributed concurrency control ensures that distributed transactions execute consistently across multiple data servers. It extends concurrency control techniques from centralized databases to account for dependencies across servers. There are three main approaches: locking, timestamp ordering, and optimistic concurrency control. Active replication involves all replicas processing requests identically to tolerate failures, while passive replication uses a primary server and backups to provide fault tolerance in a less computationally intensive manner. Distributed deadlocks can occur when transactions on different servers form a cyclic wait-for graph through their locking dependencies.

Uploaded by

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

ASSIGNMENT-6

DISTRIBUTED SYSTEMS
1.What is meant by concurrency control and how it is important in
distributed systems?

ANS: Distributed concurrency control provides concepts and technologies to


synchronize distributed transactions in a way that their interleaved execution
does not violate the ACID properties. Distributed transactions are executed in
a distributed database environment, where a set of connected data servers host
related data. A distributed transaction consists of a set of subtransactions, each
of which is executed by one data server. Distributed concurrency control
makes sure that all subtransactions of a set of distributed transactions are
serialized identically in all data servers involved. Therefore, not only local
dependencies need to be taken into account, but also dependencies involving
multiple data servers. Concurrency control techniques known from centralized
database systems need to be extended to cope with the new requirements
imposed by the distribution aspect.

Locking:

In a distributed transaction, the locks on an object are held locally (in the same
server). The local lock manager can decide whether to grant a lock or make the
requesting transaction wait.

Timestamp ordering concurrency control:


In a single server transaction, the coordinator issues a unique timestamp to each
transaction when it starts.

Optimistic concurrency control:

Recall that with optimistic concurrency control, each transaction is validated


before it is allowed to commit.

2.      Write about active and passive replication?

ANS: Active replication:


In the active model of replication for fault tolerance (see Figure 18.4), the
replica managers are state machines that play equivalent roles and are organized
as a group. Front ends multicast their requests to the group of replica managers
and all the replica managers process the request independently but identically
and reply. If any replica manager crashes, this need have no impact upon the
performance of the service, since the remaining replica managers continue to
respond in the normal way. We shall see that active replication can tolerate
Byzantine failures, because the front end can collect and compare the replies it
receives.

Under active replication, the sequence of events when a client requests an


operation to be performed is as follows:

1. Request: The front end attaches a unique identifier to the request and
multicasts it to the group of replica managers, using a totally ordered, reliable
multicast primitive. The front end is assumed to fail by crashing at worst. It
does not issue the next request until it has received a response.
2. Coordination: The group communication system delivers the request to every
correct replica manager in the same (total) order.

Passive (primary-backup) replication:


In the passive or primary-backup model of replication for fault tolerance
(Figure 18.3), there is at any one time a single primary replica manager and one
or more secondary replica managers – ‘backups’ or ‘slaves’. In the pure form of
the model, front ends communicate only with the primary replica manager to
obtain the service. The primary replica manager executes the operations and
sends copies of the updated data to the backups. If the primary fails, one of the
backups is promoted to act as the primary.

The sequence of events when a client requests an operation to be performed is


as follows:

1. Request: The front end issues the request, containing a unique identifier, to
the primary replica manager.

2. Coordination: The primary takes each request atomically, in the order in


which it receives it. It checks the unique identifier, in case it has already
executed the request, and if so it simply resends the response.
3. Execution: The primary executes the request and stores the response.

4. Agreement: If the request is an update, then the primary sends the updated
state, the response and the unique identifier to all the backups. The backups
send an acknowledgement.

5. Response: The primary responds to the front end, which hands the response
back to the client.

In the distributed systems research area replication is mainly used to provide


fault tolerance. The entity being replicated is a process. Two replication
strategies have been used in distributed systems: Active and Passive replication.

In active replication each client request is processed by all the servers. Active


Replication was first introduced by Leslie Lamport under the name state
machine replication. This requires that the process hosted by the servers
is deterministic. Deterministic means that, given the same initial state and a
request sequence, all processes will produce the same response sequence and
end up in the same final state. In order to make all the servers receive the same
sequence of operations, an atomic broadcast protocol must be used. An atomic
broadcast protocol guarantees that either all the servers receive a message or
none, plus that they all receive messages in the same order. The big
disadvantage for active replication is that in practice most of the real world
servers are non‐deterministic. Still active replication is the preferable choice
when dealing with real time systems that require quick response even under the
presence of faults or with systems that must handle byzantine faults.

In passive replication there is only one server (called primary) that processes


client requests. After processing a request, the primary server updates the state
on the other (backup) servers and sends back the response to the client. If the
primary server fails, one of the backup servers takes its place. Passive
replication may be used even for non‐deterministic processes. The disadvantage
of passive replication compared to active is that in case of failure the response is
delayed.

3.Explain about distributed deadlock?

ANS: Distributed deadlocks:


The discussion of deadlocks showed that deadlocks can arise within a single
server when locking is used for concurrency control. Servers must either
prevent or detect and resolve deadlocks.
In the above example, the local wait-for graphs of the servers are:

server Y: U o V (added when U requests b.withdraw(30))

server Z: V o W (added when V requests c.withdraw(20))

server X: W o U (added when W requests a.withdraw(20))

TRANSACTION RECOVERY:
The requirements for durability and failure atomicity are not really independent
of one another and can be dealt with by a single mechanism – the recovery
manager. The tasks of a recovery manager are:

• to save objects in permanent storage (in a recovery file) for committed


transactions;

• to restore the server’s objects after a crash;

• to reorganize the recovery file to improve the performance of recovery;

• to reclaim storage space (in the recovery file).

Entries in recovery file • To deal with recovery of a server that can be involved
in distributed transactions, further information in addition to the values of the
objects is stored in the recovery file.

You might also like