Warning:
JavaScript is turned OFF. None of the links on this page will work until it is reactivated.
If you need help turning JavaScript On, click here.
This Concept Map, created with IHMC CmapTools, has information related to: Ch 14, concurrency control in distributed transactions includes 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 therefore if transaction T is before transaction U in their conflicting access to objects at one of the servers then they must be in that order at all of the servers whose objects are accessed in a conflicting manner by both T and U, atomic commit protocols Failure model for commit protocols this applies to the two-phase commit protocol Commit protocols are designed to work in asynchronous system (e.g. messages may take a very long time) servers may crash messages may be lost. assume corrupt and duplicated messages are removed. no byzantine faults – servers either crash or they obey their requests 2PC is an example of a protocol for reaching a consensus. Chapter 12 says consensus cannot be reached in an asynchronous system if processes sometimes fail. however, 2PC does reach consensus under those conditions. because crash failures of processes are masked by replacing a crashed process with a new process whose state is set from information saved in permanent storage and information held by other processes., concurrency control in distributed transactions Timestamp ordering concurrency control Single server transactions coordinator issues a unique timestamp to each transaction before it starts serial equivalence ensured by committing objects in order of timestamps Distributed transactions the first coordinator accessed by a transaction issues a globally unique timestamp as before the timestamp is passed with each object access the servers are jointly responsible for ensuring serial equivalence that is if T access an object before U, then T is before U at all objects coordinators agree on timestamp ordering a timestamp consists of a pair <local timestamp, server-id>. the agreed ordering of pairs of timestamps is based on a comparison in which the server-id part is less significant – they should relate to time, atomic commit protocols Atomic commit protocols transaction atomicity requires that at the end, either all of its operations are carried out or none of them. in a distributed transaction, the client has requested the operations at more than one server one-phase atomic commit protocol the coordinator tells the participants whether to commit or abort what is the problem with that? this does not allow one of the servers to decide to abort – it may have discovered a deadlock or it may have crashed and been restarted two-phase atomic commit protocol is designed to allow any participant to choose to abort a transaction phase 1 - each participant votes. If it votes to commit, it is prepared. It cannot change its mind. In case it crashes, it must save updates in permanent store phase 2 - the participants carry out the joint decision, atomic commit protocols two-phase commit protocol During the progress of a transaction, the only communication between coordinator and participant is the join request The client request to commit or abort goes to the coordinator if client or participant request abort, the coordinator informs the participants immediately if the client asks to commit, the 2PC comes into use 2PC voting phase: coordinator asks all participants if they can commit if yes, participant records updates in permanent storage and then votes completion phase: coordinator tells all participants to commit or abort the next slide shows the operations used in carrying out the protocol, concurrency control in distributed transactions Locking In a distributed transaction, the locks on an object are held by the server that manages it. The local lock manager decides whether to grant a lock or make the requesting transaction wait. it cannot release any locks until it knows that the transaction has been committed or aborted at all the servers involved in the transaction. the objects remain locked and are unavailable for other transactions during the atomic commit protocol an aborted transaction releases its locks after phase 1 of the protocol., atomic commit protocols two-phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a canCommit? request to each of the participants in the transaction. 2. When a participant receives a canCommit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). (a)If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a doCommit request to each of the participants. (b)Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a doCommit or doAbort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a haveCommitted call as confirmation to the coordinator