Unit v-Distributed Transaction and Replication

UNIT V
Distributed transactions and Replication

Contents
Distributed transactions and Replication: Concurrency control
in distributed transactions – Distributed deadlocks –
Transaction recovery. Replication: System model and group
communications – fault– tolerant services

Concurrency control in distributed transactions
● Each server manages a set of objects and is responsible for ensuring
that they remain consistent when accessed by concurrent
transactions.
● Therefore, each server is responsible for applying concurrency
control to its own objects.
● The members of a collection of servers of distributed transactions
are jointly responsible for ensuring that they are performed in a
serially equivalent manner.

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.
● However, it cannot release any locks until it knows that the transaction
has been committed or aborted at all the servers involved in the
transaction
● When locking is used for concurrency control, the objects remain locked
and are unavailable for other transactions during the atomic commit
protocol

● As lock managers in different servers set their locks independently of
one another, it is possible that different servers may impose different
orderings on transactions

● The transaction T locks object A at server X, and then transaction U locks object B at server
Y.
● After that, T tries to access B at server Y and waits for U’s lock. Similarly, transaction U
tries to access A at server X and has to wait for T’s lock.
● Therefore, we have T before U in one server and U before T in the other.
● These different orderings can lead to cyclic dependencies between transactions, giving rise to
a distributed deadlock situation.
○ When a deadlock is detected, a transaction is aborted to resolve the deadlock.
○ In this case, the coordinator will be informed and will abort the transaction at the
participants involved in the transaction.

Timestamp ordering concurrency control
● In a single server transaction, the coordinator issues a unique timestamp
to each transaction when it starts
● In distributed transactions, we require that each coordinator issue
globally unique timestamps.
● A globally unique transaction timestamp is issued to the client by the
first coordinator accessed by a transaction.
● The transaction timestamp is passed to the coordinator at each server
whose objects perform an operation in the transaction.

● The servers of distributed transactions are jointly responsible for
ensuring that they are performed in a serially equivalent manner.
● For example, if the version of an object accessed by transaction U
commits after the version accessed by T at one server, if T and U access
the same object as one another at other servers they must commit them
in the same order.
● To achieve the same ordering at all the servers, the coordinators must
agree as to the ordering of their timestamps.
● A timestamp consists of a <local timestamp, server-id> pair.
● The agreed ordering of pairs of timestamps is based on a comparison in
which the server-id part is less significant.

● The same ordering of transactions can be achieved at all the servers
even if their local clocks are not synchronized.
● However, for reasons of efficiency it is required that the timestamps
issued by one coordinator be roughly synchronized with those issued by
the other coordinators.
● When this is the case, the ordering of transactions generally corresponds
to the order in which they are started in real time.
● Timestamps can be kept roughly synchronized by the use of synchronized
local physical clocks

Optimistic concurrency control
● Each transaction is validated before it is allowed to commit.
● Transaction numbers are assigned at the start of validation and
transactions are serialized according to the order of the transaction
numbers
● A distributed transaction is validated by a collection of independent
servers, each of which validates transactions that access its own
objects.
● This validation takes place during the first phase of the two-phase
commit protocol

Unit v-Distributed Transaction and Replication

● The transactions access the objects in the order T before U at server X and in the order U
before T at server Y.
● Therefore each server will be unable to validate the other transaction until the first one has
completed. This is an example of commitment deadlock.
● Now suppose that T and U start validation at about the same time, but server X validates T
first and server Y validates U first a simplification of the validation protocol that makes a rule
that only one transaction may perform validation and update phases at a time
● working phase-Each transaction has a tentative version (private workspace) of the
objects it updates - copy of the most recently committed version. Write operations
record new values as tentative values.
● validation phase-Before a transaction can commit, a validation is performed on all the
data items to see whether the data conflicts with operations of other transactions. This
is the validation phase.
● update phase-If the validation fails, then the transaction will have to be aborted and
restarted later. If the transaction succeeds, then the changes in the tentative version
are made permanent. This is the update phase.

● In distributed optimistic transactions, each server applies a parallel validation
protocol.
● This is an extension of either backward or forward validation to allow multiple
transactions to be in the validation phase at the same time
○ Backward Validation:
■ Check whether the committing transaction intersects its read/write sets
with those of any transactions that have already committed.
○ Forward Validation:
■ Check whether the committing transaction intersects its read/write sets
with any active transactions that have not yet committed.
■ A transaction in validation is compared against all transactions that
haven't yet committed

● if servers simply perform independent validations, it is possible that different
servers in a distributed transaction may serialize the same set of transactions in
different orders – for example, with T before U at server X and U before T at
server Y, in our example.
● The servers of distributed transactions must prevent this happening.
● One approach is that after a local validation by each server, a global validation is
carried out
○ The global validation checks that the combination of the orderings at the
individual servers is serializable; that is, that the transaction being validated
is not involved in a cycle.

● Another approach is that all of the servers of a particular transaction use the same
globally unique transaction number at the start of the validation
○ Coordinator of the two-phase commit protocol is responsible for generating
the globally unique transaction number and passes it to the participants in the
canCommit? messages.
○ As different servers may coordinate different transactions, the servers must
have an agreed order for the transaction numbers they generate.

Distributed deadlocks
● In a distributed system involving multiple servers being accessed by multiple
transactions, a global wait-for graph can in theory be constructed from the local
ones.
● There can be a cycle in the global wait-for graph that is not in any single local one
– that is, there can be a distributed deadlock.
● The wait-for graph is a directed graph in which nodes represent transactions and
objects, and edges represent either an object held by a transaction or a
transaction waiting for an object.
● There is a deadlock if and only if there is a cycle in the wait-for graph.

● In figure, The complete wait-for graph shows that a deadlock cycle consists of
alternate edges, which represent a transaction waiting for an object and an object
held by a transaction.
● Detection of a distributed deadlock requires a cycle to be found in the global
transaction wait-for graph that is distributed among the servers that were
involved in the transactions.
● In the above example, the local wait-for graphs of the servers are:
○ server Y: U -> V (added when U requests b.withdraw(30))
○ server Z: V -> W (added when V requests c.withdraw(20))
○ server X: W -> U (added when W requests a.withdraw(20))
● As the global wait-for graph is held in part by each of the several servers involved,
communication between these servers is required to find cycles in the graph.

Centralized deadlock detection
● A simple solution is to use centralized deadlock detection, in which one server takes on the
role of global deadlock detector.
● From time to time, each server sends the latest copy of its local wait-for graph to the global
deadlock detector, which amalgamates the information in the local graphs in order to
construct a global wait-for graph.
● The global deadlock detector checks for cycles in the global wait-for graph
● When it finds a cycle, it makes a decision on how to resolve the deadlock and tells the servers
which transaction to abort
Drawback:
● Centralized deadlock detection is not a good idea, because it depends on a single server to
carry it out.
● Poor availability,
● lack of fault tolerance and no ability to scale.
● In addition, the cost of the frequent transmission of local wait-for graphs is high.

Phantom deadlocks
● A deadlock that is ‘detected’ but is not really a deadlock is called a phantom
deadlock.
● In distributed deadlock detection, information about wait-for relationships
between transactions is transmitted from one server to another.
● If there is a deadlock, the necessary information will eventually be collected in
one place and a cycle will be detected.
● As this procedure will take some time, there is a chance that one of the
transactions that holds a lock will meanwhile have released it, in which case the
deadlock will no longer exist

Example
● Consider the case of a global deadlock detector that receives local wait-for graphs
from servers X and Y, as shown in Figure
● Suppose that transaction U then releases an object at server X and requests the
one held by V at server Y.
● Suppose also that the global detector receives server Y’s local graph before
server X’s.
● In this case, it would detect a cycle T -> U -> V -> T, although the edge T -> U no
longer exists.
● This is an example of a phantom deadlock.

Edge chasing
● A distributed approach to deadlock detection uses a technique called edge
chasing or path pushing
● In this approach, the global wait-for graph is not constructed, but each of
the servers involved has knowledge about some of its edges.
● The servers attempt to find cycles by forwarding messages called probes,
which follow the edges of the graph throughout the distributed system.
● A probe message consists of transaction wait-for relationships representing
a path in the global wait-for graph.

Edge-chasing algorithms have three steps:
Initiation
● When a server notes that a transaction T starts waiting for another
transaction U, where U is waiting to access an object at another server, it
initiates detection by sending a probe containing the edge < T -> U > to the
server of the object at which transaction U is blocked
Detection
● Detection consists of receiving probes and deciding whether a deadlock has
occurred and whether to forward the probes.

● For example, when a server of an object receives a probe < W -> U > ,it checks
to see whether U is also waiting.
● If it is, the transaction it waits for (for example, V) is added to the probe <
W ->U-> V) and if the new transaction (V) is waiting for another object
elsewhere, the probe is forwarded.
● Before forwarding a probe, the server checks to see whether the transaction
(for example, W) it has just added has caused the probe to contain a cycle
(for example, < W -> U -> V -> W >).
● If this is the case, it has found a cycle in the graph and a deadlock has
been detected.
Resolution: When a cycle is detected, a transaction in the cycle is aborted to
break the deadlock.

In our example, the following steps describe how deadlock detection is initiated and
the probes that are forwarded during the corresponding detection phase:
● Server X initiates detection by sending probe < W -> U > to the server of B
(Server Y).
● Server Y receives probe < W -> U >, notes that B is held by V and appends V to the
probe to produce < W -> U -> V >. It notes that V is waiting for C at server Z. This
probe is forwarded to server Z.
● Server Z receives probe < W -> U -> V >, notes C is held by W and appends W to
the probe to produce < W -> U -> V -> W >.
This path contains a cycle. The server detects a deadlock. One of the transactions in
the cycle must be aborted to break the deadlock
A probe that detects a cycle involving N transactions will be forwarded by (N – 1)
transaction coordinators via (N – 1) servers of objects, requiring 2(N – 1) messages.

Transaction priorities
● In Figure 17.16(a) Consider transactions T, U, V and W, where U is waiting for
W and V is waiting for T.
● At about the same time, T requests the object held by U and W requests the
object held by V.
● Two separate probes, < T -> U > and < W -> V >, are initiated by the servers of
these objects and are circulated until deadlocks are detected by each of the
servers.
● In Figure 17.16(b), the cycle is < T -> U -> W -> V -> T > and in Figure
17.16 (c), the cycle is < W -> V -> T -> U -> W >.

● In order to ensure that only one transaction in a cycle is aborted,
transactions are given priorities in such a way that all transactions are totally
ordered.
● Timestamps, for example, may be used as priorities.
● When a deadlock cycle is found, the transaction with the lowest priority is
aborted.
● In the above example, assume T > U > V > W.
● Then the transaction W will be aborted when either of the cycles < T -> U
-> W -> V -> T > or < W -> V -> T -> U -> W > is detected.

● Transaction priorities could also be used to reduce the number of situations
that cause deadlock detection to be initiated, by using the rule that
○ Detection is initiated only when a higher-priority transaction starts to
wait for a lower-priority one.
● In the example, T > U the initiating probe < T -> U > would be sent, but as W <
V the initiating probe < W -> V > would not be sent.
● Transaction priorities could also be used to reduce the number of probes
that are forwarded.
● The general idea is that probes should travel ‘downhill’ – that is, from
transactions with higher priorities to transactions with lower priorities

● Consider transactions U, V and W are executed in an order in which U is
waiting for V and V is waiting for W when W starts waiting for U.
● Without priority rules, detection is initiated when W starts waiting by
sending a probe < W -> U>.
● Under the priority rule, this probe will not be sent because W < U and the
deadlock will not be detected.
● The problem is that the order in which transactions start waiting can
determine whether or not a deadlock will be detected.

Probe queue
● The above pitfall can be avoided by using a scheme in which coordinators save
copies of all the probes received on behalf of each transaction in a probe queue.
● When a transaction starts waiting for an object, it forwards the probes in its
queue to the server of the object, which propagates the probes on downhill routes.
● When an algorithm requires probes to be stored in probe queues, it discards
probes that refer to transactions that have been committed or aborted.
● If relevant probes are discarded, undetected deadlocks may occur, and if
outdated probes are retained, false deadlocks may be detected. This adds much to

Transaction recovery
● we assume that when a server is running it keeps all of its objects in its volatile
memory and records its committed objects in a recovery file or files.
● Therefore recovery consists of restoring the server with the latest committed
versions of its objects from permanent storage
● 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).

Intentions list
● At each server, an intentions list is recorded for all of its currently active
transactions
● An intentions list of a particular transaction contains a list of the references and
the values of all the objects that are altered by that transaction.
● When a transaction is committed, that transaction’s intentions list is used to
identify the objects it affected.
● The committed version of each object is replaced by the tentative version made
by that transaction, and the new value is written to the server’s recovery file.
● When a transaction aborts, the server uses the intentions list to delete all the
tentative versions of objects made by that transaction.

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.
● This information concerns the status of each transaction whether it is committed,
aborted or prepared to commit.
● In addition, each object in the recovery file is associated with a particular
transaction by saving the intentions list in the recovery file.

Two approaches to the use of recovery files
● logging and
● shadow versions.
1.Logging
● In the logging technique, the recovery file represents a log containing the history
of all the transactions performed by a server.
● The history consists of values of objects, transaction status entries and
transaction intentions lists
● The order of the entries in the log reflects the order in which transactions have
prepared, committed and aborted at that server.

● In practice, the recovery file will contain a recent snapshot of the values of all the
objects in the server followed by a history of transactions postdating the
snapshot.
● During the normal operation of a server, its recovery manager is called whenever a
transaction prepares to commit, commits or aborts a transaction.
● When the server is prepared to commit a transaction, the recovery manager
appends all the objects in its intentions list to the recovery file, followed by the
current status of that transaction (prepared) together with its intentions list.
● When a transaction is eventually committed or aborted, the recovery manager
appends the corresponding status of the transaction to its recovery file.
● An additional advantage of the logging technique is that sequential writes to disk
are faster than writes to random locations

● If the server fails, only the last write can be incomplete.
● After a crash, any transaction that does not have a committed status in the log is aborted. Therefore when a
transaction commits, its committed status entry must be forced to the log
● The recovery manager associates a unique identifier with each object
● The figure illustrates the log mechanism for the banking service transactions T and U
○ The log was recently reorganized, and entries to the left of the double line represent a snapshot of the
values of A, B and C before transactions T and U started
○ When transaction T prepares to commit, the values of objects A and B are written at positions P1 and
P2 in the log, followed by a prepared transaction status entry for T with its intentions list (< A, P1 >, < B,
P2 >).
○ When transaction T commits, a committed transaction status entry for T is put at position P4.
○ Then when transaction U prepares to commit, the values of objects C and B are written at positions P5
and P6 in the log, followed by a prepared transaction status entry for U with its intentions list (< C, P5 >,
< B, P6 >).
○ Each transaction status entry contains a pointer to the position in the recovery file of the previous
transaction status entry

Recovery of objects
● When a server is replaced after a crash, it first sets default initial values for
its objects and then hands over to its recovery manager.
● The recovery manager is responsible for restoring the server’s objects so
that they include all the effects of the committed transactions performed in
the correct order and none of the effects of incomplete or aborted
transactions.
● There are two approaches to restoring the data from the recovery file.
● In the first,
○ the recovery manager starts at the beginning and restores the
values of all of the objects from the most recent checkpoint

● In the second,
○ the recovery manager will restore a server’s objects by ‘reading the recovery file
backwards’.
○ The recovery file has been structured so that there is a backwards pointer from each
transaction status entry to the next.
○ The recovery manager uses transactions with committed status to restore those objects
that have not yet been restored.
○ In the figure 17.19, It starts at the last transaction status entry in the log (at P7) and
concludes that transaction U has not committed and its effects should be ignored.
○ It then moves to the previous transaction status entry in the log (at P4) and concludes that
transaction T has committed.
○ To recover the objects affected by transaction T, it moves to the previous transaction
status entry in the log (at P3) and finds the intentions list for T (< A, P1 >, < B, P2 >).
○ It then restores objects A and B from the values at P1 and P2. As it has not yet restored C,
it moves back to P0, which is a checkpoint, and restores C.

Reorganizing the recovery file
● A recovery manager is responsible for reorganizing its recovery file so as to
make the process of recovery faster and to reduce its use of space
● The name checkpointing is used
○ to refer to the process of writing the current committed values of a
server’s objects to a new recovery file,
○ together with transaction status entries and
○ intentions lists of transactions that have not yet been fully resolved
● The term checkpoint is used to refer to the information stored by the
checkpointing process.

● The purpose of making checkpoints is to reduce the number of transactions
to be dealt with during recovery and to reclaim file space.
● Checkpointing consists of
○ ‘adding a mark’ to the recovery file when the checkpointing starts,
writing the server’s objects to the future recovery file and
○ then copying to that file
■ (1) all entries before the mark that relate to as-yet-unresolved
transactions and
■ (2) all entries after the mark in the recovery file.

2.Shadow versions
● The logging technique records transaction status entries, intentions lists and
objects all in the same file – the log.
● The shadow versions technique is an alternative way to organize a recovery
file.
● It uses a map to locate versions of the server’s objects in a file called a
version store.
● The map associates the identifiers of the server’s objects with the positions
of their current versions in the version store.
● The versions written by each transaction are ‘shadows’ of the previous
committed versions.

● When a transaction is prepared to commit, any of the objects changed by the
transaction are appended to the version store, leaving the corresponding
committed versions unchanged.
● These new as-yet-tentative versions are called shadow versions.
● When a transaction commits, a new map is made by copying the old map and
entering the positions of the shadow versions.
● To complete the commit process, the new map replaces the old map.
● To restore the objects when a server is replaced after a crash, its recovery
manager reads the map and uses the information in the map to locate the
objects in the version store.

● Figure 17.20 illustrates this technique with the same example involving transactions T and U
● The first column in the table shows the map before transactions T and U, when the balances
of the accounts A, B and C are $100, $200 and $300, respectively.
● The second column shows the map after transaction T has committed. The version store
contains a checkpoint, followed by the versions of A and B at P1 and P2 made by transaction T.
● It also contains the shadow versions of B and C made by transaction U, at P3 and P4.
● The switch from the old map to the new map must be performed in a single atomic step.
Advantages over logging
● The shadow versions method provides faster recovery than logging because the positions of
the current committed objects are recorded in the map, whereas recovery from a log requires
searching throughout the log for objects

● Transaction status entries and intentions lists are saved in a file called the transaction
status file.
● Each intentions list represents the part of the map that will be altered by a transaction
when it commits. The transaction status file may, for example, be organized as a log.
● The figure below shows the map and the transaction status file for our current example
when T has committed and U is prepared to commit:

3.The need for transaction status and intentions list entries in a recovery file
● The intentions lists in the recovery file is essential for a server that is intended to participate
in distributed transactions.
● This approach can also be useful for servers of nondistributed transactions for various
reasons, including the following:
○ Some recovery managers are designed to write the objects to the recovery file early,
under the assumption that transactions normally commit.
○ If transactions use a large number of big objects, the need to write them contiguously to
the recovery file may complicate the design of a server. When objects are referenced
from intentions lists, they can be found wherever they are.
○ In timestamp ordering concurrency control, a server sometimes knows that a transaction
will eventually be able to commit and acknowledges the client – at this time, the objects
are written to the recovery file to ensure their permanence.

4.Recovery of the two-phase commit protocol
● In a two-phase commit protocol, the recovery managers use two new status values for
this purpose: done and uncertain.
● A coordinator uses committed to indicate that the outcome of the vote is Yes and done
to indicate that the two-phase commit protocol is complete.
● A participant uses uncertain to indicate that it has voted Yes but does not yet know the
outcome of the vote
● Two additional types of entry allow a coordinator to record a list of participants and a
participant to record its coordinator

In phase 1 of the protocol,
● when the coordinator is prepared to commit its recovery manager adds a coordinator
entry to its recovery file.
● Before a participant can vote Yes, it must have already prepared to commit
● When it votes Yes, its recovery manager records a participant entry and adds an
uncertain transaction status to its recovery file as a forced write.
● When a participant votes No, it adds an abort transaction status to its recovery file.
In phase 2 of the protocol
● When a coordinator has received a confirmation from all of its participants, its
recovery manager adds a done transaction status to its recovery file

● Figure 17.21 shows the entries in a log for transaction T, in which the server played
the coordinator role, and for transaction U, in which the server played the participant
role.
● For both transactions, the prepared transaction status entry comes first.
● In the case of a coordinator it is followed by a coordinator entry and a committed
transaction status entry.
● The done transaction status entry is not shown in Figure 17.21
● In the case of a participant, the prepared transaction status entry is followed by a
participant entry whose state is uncertain and then a committed or aborted transaction
status entry.

Recovery of the two-phase commit protocol

Reorganization of recovery file
● Care must be taken when performing a checkpoint to ensure that coordinator entries of
transactions without status done are not removed from the recovery file.
● These entries must be retained until all the participants have confirmed that they have
completed their transactions.
● Entries with status done may be discarded.
● Participant entries with transaction state uncertain must also be retained.
Recovery of nested transactions
● In the simplest case, each subtransaction of a nested transaction accesses a different
set of objects.
● As each participant prepares to commit during the two-phase commit protocol, it writes
its objects and intentions lists to the local recovery file, associating them with the
transaction identifier of the top-level transaction

● However, abort recovery is complicated by the fact that several subtransactions at the
same and different levels in the nesting hierarchy can access the same object.
● To support recovery from aborts, the server of an object shared by transactions at
multiple levels provides a stack of tentative versions – one for each nested transaction
to use.
● When one of its subtransactions does access the same object, it copies the version at
the top of the stack and pushes it back onto the stack. All of that subtransaction’s
updates are applied to the tentative version at the top of the stack
● When a subtransaction aborts, its version at the top of the stack is discarded.
● when the top-level transaction commits, the version at the top of the stack becomes
the new committed version.

REPLICATION
● Replication-the maintenance of copies of data at multiple computers.
● Replication is a key to the effectiveness of distributed systems in
that it can provide
○ enhanced performance,
○ high availability and
○ fault tolerance

Replication is a technique for enhancing services. The motivations for
replication include:
● Performance enhancement: The caching of data at clients and servers
is by now familiar as a means of performance enhancement
● Increased availability: Users require services to be highly available.
That is, the proportion of time for which a service is accessible with
reasonable response times should be close to 100%.
● Fault tolerance:A fault-tolerant service, by contrast, always
guarantees strictly correct behaviour despite a certain number and
type of faults.

System model and the role of group communication
1.System model
● The general model of replica management is shown in Figure 18.1
● A collection of replica managers provides a service to clients.
● The clients see a service that gives them access to objects which in fact are replicated
at the managers.
● Each client requests a series of operations – invocations upon one or more of the
objects.
● An operation may involve a combination of reads of objects and updates to objects.
○ Requested operations that involve no updates are called read only requests;

● Each client’s requests are first handled by a component called a front
end.
● The role of the front end is
○ To communicate by message passing with one or more of the replica
managers, rather than forcing the client to do this itself explicitly.
○ It is the vehicle for making replication transparent.
○ It may be implemented in the client’s address space, or it may be a
separate process.

In general, five phases are involved in the performance of a single
request upon the replicated objects
○ Request
○ Coordination
○ Execution
○ Agreement
○ Response

Request:
The front end issues the request to one or more replica managers:
● either the front end communicates with a single replica manager, which in turn communicates
with other replica managers; or
● the front end multicasts the request to the replica managers.
Coordination:
● The replica managers coordinate in preparation for executing the request consistently
● They also decide on the ordering of this request relative to others
○ FIFO ordering: If a front end issues request r and then request r’, any correct replica
manager that handles r’ handles r before it.
○ Causal ordering: If the issue of request r happened-before the issue of request r’, then
any correct replica manager that handles r’ handles r before it.
○ Total ordering: If a correct replica manager handles r before request r’, then any
correct replica manager that handles r’ handles r before it.

Execution:
The replica managers execute the request – perhaps tentatively: that is, in such a way
that they can undo its effects later.
Agreement:
The replica managers reach consensus on the effect of the request – if any – that will
be committed. For example, in a transactional system the replica managers may
collectively agree to abort or commit the transaction at this stage

Response:
● One or more replica managers responds to the front end.
● In some systems, one replica manager sends the response.
● In others, the front end receives responses from a collection of replica
managers and selects or synthesizes a single response to pass back to the
client.
● For example, it could pass back the first response to arrive, if high
availability is the goal.
● If tolerance of Byzantine failures is the goal, then it could give the client
the response that a majority of the replica managers provides.

2.The role of group communication
● In Group membership management, Systems that can adapt as processes join,
leave and crash
● In particular fault-tolerant systems, require the more advanced features of
failure detection and notification of membership changes.
● A full group membership service maintains group views, which are lists of the
current group members, identified by their unique process identifiers.
● The list is ordered, for example, according to the sequence in which the members
joined the group.
● A new group view is generated each time that a process is added or excluded.

● An important consideration is how a group management service treats network
partitions.
○ Disconnection or the failure of components such as a router in a network may split
a group of processes into two or more subgroups, with communication between the
subgroups impossible
● On the other hand, in some circumstances it is acceptable for two or more subgroups to
continue to operate a partitionable group membership service allows this.
○ For example, in an application in which users hold an audio or video conference to
discuss some issues, it may be acceptable for two or more subgroups of users to
continue their discussions independently

(i)View delivery
● Consider the task of a programmer writing an application that runs in each process in a
group and that must cope with new and lost members.
● The programmer needs to know that the system treats each member in a consistent way
when the membership changes
● Group view--> The lists of the current group members
● Deliver a view
○ when a membership change occurs, the application is notified of the new
membership
○ Group management service delivers to any member process p belongsto g a series of
views v0(g), v1(g), v2(g), etc •
○ A series of views would be v0(g)=(p), v1(g)=(p,p’), v2(g)=(p)
■ p joins an empty group, then p’ joins the group, then p’ leaves it

● Some basic requirements for view delivery are as follows:
○ Order: If a process p delivers view v(g) and then view v’(g), then no other
process q ≠ p delivers v’(g) before v(g).
○ Integrity: If process p delivers view v(g), then p belongsto v(g).
○ Non-triviality: If process q joins a group and is or becomes indefinitely
reachable from process p ≠ q, then eventually q is always in the views that
p delivers.

(ii)View-synchronous group communication
● A view-synchronous group communication system makes guarantees additional to those
above about the delivery ordering of view notifications with respect to the delivery of
multicast messages.
● The guarantees provided by view synchronous group communication are as follows:
○ Agreement: Correct processes deliver the same sequence of views and the same
set of messages in any given view. That is, if a correct process delivers message m
in view v(g), then all other correct processes that deliver m also do so in the view
v(g).
○ Integrity: If a correct process p delivers message m, then it will not deliver m
again. Furthermore, p £ group(m) and the process that sent m is in the view in
which p delivers m.

○ Validity (closed groups):
■ Correct processes always deliver the messages that they send.
■ If the system fails to deliver a message to any process q, then it
notifies the surviving processes by delivering a new view with q
excluded, immediately after the view in which any of them delivered
the message.
■ That is, let p be any correct process that delivers message m in view
v(g).
■ If some process q £ v(g) does not deliver m in view v(g), then the
next view v’(g) that p delivers has q (not belongs to) v’(g).

● Consider a group with three processes, p, q and r (see Figure 18.2).
● Suppose that p sends a message m while in view (p, q, r) but that p crashes soon after
sending m, while q and r are correct.
● One possibility is that p crashes before m has reached any other process.
○ In this case, q and r each deliver the new view (q, r), but neither ever delivers m
(Figure 18.2a).
● The other possibility is that m has reached at least one of the two surviving processes
when p crashes.
○ Then q and r both deliver first m and then the view (q, r) (Figure 18.2b).
○ It is not allowed for q and r to deliver first the view (q, r) and then m (Figure
18.2c), since then they would deliver a message from a process that they have been
informed has failed;
○ nor can the two deliver the message and the new view in opposite orders (Figure
18.2d).

● In a view-synchronous system, the delivery of a new view draws a conceptual line
across the system and every message that is delivered at all is consistently
delivered on one side or the other of that line.
● This enables the programmer to draw useful conclusions about the set of messages
that other correct processes have delivered when it delivers a new view, based
only on the local ordering of message delivery and view delivery events.
● An illustration of the usefulness of view-synchronous communication is how it can
be used to achieve state transfer –
○ the transfer of the working state from a current member of a process group
to a new member of the group

Fault– tolerant services
What is fault tolerant service?
● Fault tolerance refers to the ability of a system (computer,
network, cloud cluster, etc.) to continue operating without
interruption when one or more of its components fail.
● Fault-tolerant systems use backup components that
automatically take the place of failed components, ensuring no
loss of service.

● Consider a naive replication system, in which a pair of replica managers at
computers A and B each maintain replicas of two bank accounts, x and y.
● Clients read and update the accounts at their local replica manager but try another
replica manager if the local one fails.
● Replica managers propagate updates to one another in the background after
responding to the clients.
● Both accounts initially have a balance of $0.
● Client 1 updates the balance of x at its local replica manager B to be $1 and then
attempts to update y’s balance to be $2, but discovers that B has failed.
● Client 1 therefore applies the update at A instead. Now client 2 reads the balances
at its local replica manager A.
● It finds first that y has $2 and then that x has $0 – the update to bank account x
from B has not arrived, since B failed.

Linearizability and sequential consistency
● Linearizability cares about time.
● Sequential consistency cares about program order.
1.Linearizability
● There are various correctness criteria for replicated objects. The most strictly correct
systems are linearizable, and this property is called linearizability.
● In order to understand linearizability, consider a replicated service implementation with
two clients.
● Let the sequence of read and update operations that client i performs in some

● Each operation oij in these sequences is specified by the operation type and the
arguments and return values as they occurred at runtime.
● A replicated shared object service is said to be linearizable if for any execution
there is some interleaving of the series of operations issued by all the clients that
satisfies the following two criteria:
○ The interleaved sequence of operations meets the specification of a (single)
correct copy of the objects.
○ The order of operations in the interleaving is consistent with the real times
at which the operations occurred in the actual execution.

Drawback of linearizability:
● The real-time requirement in linearizability is desirable in an ideal world, because it
captures our notion that clients should receive up-to-date information.
● But, equally, the presence of real time in the definition raises the issue of
linearizability’s practicality, because we cannot always synchronize clocks to the
required degree of accuracy

2.Sequential consistency
● A weaker correctness condition is sequential consistency, which captures an
essential requirement concerning the order in which requests are processed
without appealing to real time.
● A replicated shared object service is said to be sequentially consistent if for any
execution there is some interleaving of the series of operations issued by all the
clients that satisfies the following two criteria:
○ The interleaved sequence of operations meets the specification of a (single)
correct copy of the objects.
○ The order of operations in the interleaving is consistent with the program
order in which each individual client executed them.

● An example execution for a service that is sequentially consistent but not
linearizable follows:
● The real-time criterion for linearizability is not satisfied, since getBalance A(x)->0
occurs later than setBalanceB(x,1) ;
● but the following interleaving satisfies both criteria for sequential consistency:
getBalanceA(y) -> 0 , getBalanceA(x) -> 0 , setBalanceB(x, 1) , setBalanceA(y, 2) .

Passive (primary-backup) replication
● In the passive or primary-backup model of replication for fault tolerance 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

● This system obviously implements linearizability if the primary is correct,
since the primary sequences all the operations upon the shared objects.
● If the primary fails, then the system retains linearizability if a single backup
becomes the new primary and if the new system configuration takes over
exactly where the last left off.
● That is if:
○ The primary is replaced by a unique backup (if two clients began using
two backups, then the system could perform incorrectly).
○ The replica managers that survive agree on which operations had been
performed at the point when the replacement primary takes over.

● Consider a front end that has not received a response.
● The front end retransmits the request to whichever backup takes over as the
primary.
● The primary may have crashed at any point during the operation. If it
crashed before the agreement stage (4), then the surviving replica managers
cannot have processed the request.
● If it crashed during the agreement stage, then they may have processed the
request.
● If it crashed after that stage, then they have definitely processed it.
● But the new primary does not have to know what stage the old primary was in
when it crashed.
● When it receives a request, it proceeds from stage 2 above.

Active replication
● In the active model of replication for fault tolerance, 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.
3. Execution:
● Every replica manager executes the request.
● Since they are state machines and since requests are delivered in the same total
order, correct replica managers all process the request identically.
● The response contains the client’s unique request identifier.

4. Agreement: No agreement phase is needed, because of the multicast delivery
semantics.
5. Response:
● Each replica manager sends its response to the front end.
● The number of replies that the front end collects depends upon the failure
assumptions and the multicast algorithm.

● This system achieves sequential consistency.
● All correct replica managers process the same sequence of requests.
● The reliability of the multicast ensures that ensures that they process them
in the same order.
● Since they are state machines, they all end up with the same state as one
another after each request.
● Each front end’s requests are served in FIFO orderwhich is the same as
‘program order’. This ensures sequential consistency.
● The active replication system does not achieve linearizability.
○ This is because the total order in which the replica managers process
requests is not necessarily the same as the real-time order in which the
clients made their requests.

Unit v-Distributed Transaction and Replication

More Related Content

What's hot (20)

Similar to Unit v-Distributed Transaction and Replication (20)

More from Dhivyaa C.R (16)

Recently uploaded (20)

Unit v-Distributed Transaction and Replication