management of distributed transactions
-
Upload
nilu-desai -
Category
Technology
-
view
132 -
download
1
Transcript of management of distributed transactions
![Page 1: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/1.jpg)
Management of
distributed transactions
Nileshwari Desai
A 216
![Page 2: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/2.jpg)
Outline
• Introduction
• Framework
• Supporting atomicity
• Concurrency control
• Summarization
![Page 3: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/3.jpg)
Introduction
The management of distributed transactions require dealing with several problems which are strictly interconnected, like-
a. Reliability
b. Concurrency control
c. Efficient utilization of the resources of the whole system.
![Page 4: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/4.jpg)
Framework for transaction
management
1. Properties of transactions
2. Goals of transaction management
3. Distributed transactions
![Page 5: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/5.jpg)
1. Properties of transactions
• Atomicity
• Durability
• Serializability
• Isolation
![Page 6: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/6.jpg)
2. Goals of transaction management
• CPU and main memory utilization
• Control messages
• Response time
• Availability
![Page 7: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/7.jpg)
Lets summarize!
• The goal of transaction management in a distributed database is to control the execution of transactions so that:
1. Transactions have atomicity, durability, serializability and isolation properties.
2. Their cost in terms of main memory, CPU and number of transmitted control messages and their response time are minimized.
3. The availability of the system is maximized.
![Page 8: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/8.jpg)
3. Distributed transactions
• Agent: An agent is a local process which performs some actions on behalf of an application.
![Page 9: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/9.jpg)
An updating transaction
Updating a master tape is fault tolerant: If a run fails for any reason, all the tape
could be rewound and the job restarted with no harm done.
![Page 10: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/10.jpg)
Basic Transaction Primitives
Primitive Description
BEGIN_TRANSACTION Make the start of a transaction
END_TRANSACTION Terminate the transaction and try to commit
ABORT_TRANSACTION Kill the transaction and restore the old values
READ Read data from a file, a table
WRITE Write data to a file, a table
![Page 11: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/11.jpg)
Transaction execution
![Page 12: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/12.jpg)
Nested versus distributed transaction
![Page 13: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/13.jpg)
Flat and nested transactions
T
S
1
T22
T21
T12
T11
T2
T1
T
S
3
S
2
S
2
S
6
S
5
S
4
S
1
S
3
(a) Distributed flat (b) Distributed nested
S
7
S
0
A circle (Si) denotes a server, and a
square (Tj) represents a sub-transaction.
![Page 14: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/14.jpg)
Flat transaction send out requests to different servers and each request is completed before client goes to the next one. Nested transaction allows sub-transactions at the same level to execute concurrently.
![Page 15: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/15.jpg)
Supporting atomicity of distributed
transactions • Recovery in centralized databases
• Communication failures in distributed databases.
• Recovery of distributed transactions.
• The 2-Phase-commitment protocol
![Page 16: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/16.jpg)
1-phase atomic commit protocol
• A transaction comes to an end when the client requests that a transaction be committed or aborted.
• Simple way is: coordinator to communicate the commit or abort request to all of the participants in the transaction and to keep on repeating the request until all of them have acknowledged that they had carried it out.
• Inadequate because when the client requests a commit, it does not allow a server to make a unilateral decision to abort a transaction. E.g. deadlock avoidance may force a transaction to abort at a server when locking is used. So any server may fail or abort and client is not aware.
![Page 17: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/17.jpg)
2-phase commit protocol
• Allow any participant to abort its part of a transaction. Due to atomicity, the whole transaction must also be aborted.
• In the first phase, each participant votes for the transaction to be committed or aborted. Once voted to commit, not allowed to abort it. So before votes to commit, it must ensure that it will eventually be able to carry out its part, even if it fails and is replaced.
• A participant is said to be in a prepared state if it will eventually be able to commit it. So each participant needs to save the altered objects in the permanent storage device together with its status-prepared.
![Page 18: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/18.jpg)
2-phase commit protocol
• In the second phase, every participant in the transaction carries out the joint decision. If any one participant votes to abort, the decision must be to abort. If all the participants vote to commit, then the decision is to commit the transaction.
• The problem is to ensure that all of the participants vote and that they all reach the same decision. It is an example of consensus. It is simple if no error occurs. However, it should work when servers fail, message lost or servers are temporarily unable to communicate with one another.
![Page 19: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/19.jpg)
2-phase commit protocol
• If the client requests abort, or if the transaction is aborted by one of the participants, the coordinator informs the participants immediately.
• It is when the client asks the coordinator to commit the transaction that two-phase commit protocol comes into use.
• In the first phase, the coordinator asks all the participants if they are prepared to commit; and in the second, it tells them to commit or abort the transaction.
![Page 20: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/20.jpg)
Operations for 2-phase commit
protocol • canCommit?(trans)-> Yes / No
▫ Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote.
• doCommit(trans)
▫ Call from coordinator to participant to tell participant to commit its part of a transaction.
• doAbort(trans)
▫ Call from coordinator to participant to tell participant to abort its part of a transaction.
• haveCommitted(trans, participant)
▫ Call from participant to coordinator to confirm that it has committed the transaction.
• getDecision(trans) -> Yes / No
▫ Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages.
![Page 21: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/21.jpg)
Communication in 2-phase commit
protocol
canCommit?
Yes
doCommit
haveCommitted
Coordinator
1
3
(waiting for votes)
committed
done
prepared to commit
step
Participant
2
4
(uncertain)
prepared to commit
committed
status step status
![Page 22: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/22.jpg)
Concurrency control for distributed
transactions • Concurrency control based on locking in
centralized databases.
• Concurrency control based on locking in distributed databases.
![Page 23: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/23.jpg)
Concurrency control in distributed
transactions • Concurrency control for distributed
transactions: each server applies local concurrency control to its own objects, which ensure transactions serializability locally.
• However, the members of a collection of servers of distributed transactions are jointly responsible for ensuring that they are performed in a serially equivalent manner. Thus global serializability is required.
![Page 24: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/24.jpg)
locks
• Lock manager at each server 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.
• A lock managers in different servers set their locks independently of one another. It is possible that different servers may impose different orderings on transactions.
![Page 25: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/25.jpg)
Timestamp ordering concurrency
control • In a single server transaction, the coordinator issues
a unique timestamp to each transaction when it starts. Serial equivalence is enforced by committing the versions of objects in the order of the timestamps of transactions that accessed them.
• In distributed transactions, we require that each coordinator issue globally unique time stamps. The coordinators must agree as to the ordering of their timestamps. <local timestamp, server-id>, the agreed ordering of pairs of timestamps is based on a comparison in which the server-id is less significant.
• The timestamp is passed to each server whose objects perform an operation in the transaction.
![Page 26: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/26.jpg)
Timestamp ordering concurrency
control • To achieve the same ordering at all the servers, The
servers of distributed transactions are jointly responsible for ensuring that they are performed in a serially equivalent manner. E.g. If T commits after U at server X, T must commits after U at server Y.
• Conflicts are resolved as each operation is performed. If the resolution of a conflict requires a transaction to be aborted, the coordinator will be informed and it will abort the transaction at all the participants.
![Page 27: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/27.jpg)
locking
T U Write(A) at X locks A Write(B) at Y locks B Read(B) at Y waits for U Read(A) at X waits for T ****************************************************
************** T before U in one server X and U before T in server Y.
These different ordering can lead to cyclic dependencies between transactions and a distributed deadlock situation arises.
![Page 28: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/28.jpg)
Distributed deadlock
• Deadlocks can arise within a single server when locking is used for concurrency control. Servers must either prevent or detect and resolve deadlocks.
• Using timeout to resolve deadlock is a clumsy approach. Why? Another way is to detect deadlock by detecting cycles in a wait for graph.
![Page 29: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/29.jpg)
Distributed transaction managers must ensure that all transactions have the atomicity, durability, seriability and isolation properties. In most systems, this is obtained by implementing on top of existing local transaction managers the 2-phase-commitment protocol for reliability,2-phase-locking for concurrency control, and timeouts for deadlock detection. The 2-phase-commitment protocol ensures that the subtransactions of the same transaction will either all commit or all abort, in spite of the possible failures. 2-phase-commitment is resilient to any failure in which no log information is lost. The 2-phase-locking mechanism requires that all subtransactions acquire locks in the growing phase and release locks in the shrinking phase. Timeout mechanisms for deadlock detection simply abort those transactions which are in wait, possibly for a deadlock. Several computation and communication structures are possible for distributed transaction managers. The computation can use processes permanently assigned to transactions, or servers dynamically bound to them. Processes can have a centralized structure, in which one agent activates all other agents, or a hierarchical structure, in which each agent can in turn activate other agents. The communication can use sessions or datagrams. The communication structure of the commitment protocol can be centralized, hierarchical, linear, or distributed.
![Page 30: management of distributed transactions](https://reader034.fdocuments.us/reader034/viewer/2022042700/55693225d8b42add468b4e41/html5/thumbnails/30.jpg)
Any questions???