Research techniques for ensuring atomicity or techniques for managing concurrenc

Question

Research techniques for ensuring atomicity or techniques for managing concurrency control. Select one technique that is not detailed in the textbook for your Discussion post. In the book is serializablity, locking protocol and timestamp based protocols. I need one other than those. Please provide reference.

post a 3- to 4-paragraph evaluation of the technique you selected. Include the following in your post:

A brief summary of the technique.

A description of the concurrency issue that is resolved by the technique, as well as the advantages and disadvantages of the technique.

An explanation of whether the technique is best suited for an all-or-nothing atomicity design strategy or a before-or-after atomicity design strategy.

Explanation / Answer

The Two-Phase Commit Protocol

For atomicity to be ensured, all the sites in which a transaction T has executed must agree on the final outcome of the execution. T must either commit at all sites, or it must abort at all sites. To ensure this property, the transaction coordinator of T must execute a commit protocol. Among the simplest and most widely used commit protocols is the two-phase commit (2PC) protocol, which we discuss next. Let T be a transaction initiated at site Sj, and let the transaction coordinator at Sj be C. When T completes its execution-that is, when all the sites at which T has executed inform C that T has completed-then C starts the 2pC protocol.

• Phase 1. C adds the record <prepare T> to the log and forces the record onto stable storage. It then sends a prepare (T) message to all the sites at which T has executed. On receiving the message, the transaction manager at that site determines whether it is willing to commit its portion of T. If the answer is 110, it adds a record <no T> to the log, and then it responds by sending an abort (T) message to C. If the answer is yes, it adds a record <ready T> to the log and forces all the log records corresponding to T' onto stable storage. The transaction manager then replies with a ready (T) message to C;

• Phase 2. When C has received responses to the prepare (T) message from all the sites, or when a pre-specified interval of time has elapsed since the prepare (T) message was sent out, C can determine whether the transaction T can be committed or aborted. Transaction T can be committed if ~i has received a ready (T) message from all the participating sites. Otherwise, transaction T must be aborted. Depending on the verdict, either a record <commit T> or a record <abort T> is added to the log and is forced onto stable storage. At this point, the fate of the transaction has been sealed.

Following this, the coordinator sends either a commit (T) or an abort (T) message to all participating sites. When a site receives that message, it records the message in the log. A site at which T has executed can unconditionally abort T at any time prior

to its sending the message ready (T) to the coordinator. The ready (T) message is, in effect, a promise by a site to follow the coordinator's order to commit Tor to abort T. A site can make such a promise only when the needed information is stored in stable storage. Otherwise, if the site crashes after sending ready T, it may be unable to make good on its promise.

Since unanimity is required to commit a transaction, the fate of T is sealed as soon as at least one site responds with abort (T). Note that the coordinator site Si can decide unilaterally to abort T, as it is one of the sites at which T has executed. The final verdict regarding T is determined at the time the coordinator writes that verdict (commit or abort) to the log and forces it to stable storage.In some implementations of the 2rc protocol, a site sends an acknowledge (T) message to the coordinator at the end of the second phase of the protocol. When the coordinator has received the acknowledge (T) message from all the sites, it adds the record <complete T> to the log.

Concurrency Control:

The transaction manager of a distributed database system manages the execution of those transactions (or subtransactions) that access data stored in a local site. Each such transaction may be either a local transaction (that is, a transaction that executes only at that site) or part of a global transaction (that is, a transaction that executes at several sites). Each transaction manager is responsible for maintaining a log for recovery purposes and for participating in an appropriate concurrency-control scheme to coordinate the concurrent execution of the transactions executing at that site.

Nonreplicated Scheme

If no data are replicated in the system, then Each site maintains a local lock manager whose function is to administer the lock and unlock requests for those data

items stored in that site. When a transaction wishes to lock data item Q at site Si, it simply sends a message to the lock manager at site Si requesting a lock (in a particular lock mode). If data item Qis locked in an incompatible mode, then the request is delayed until that request can be granted. Once it has been determined that the lock request can be granted, the lock manager sends a message back to the initiator indicating that the lock request has been granted. This scheme has the advantage of simple implementation. It requires two message transfers for handling lock requests and one message transfer for handling unlock requests. However, deadlock handling is more complex.

Single-Coordinator Approach:

Several concurrency-control schemes can be used in systems that allow data

replication. Under the single-coordinator approach, the system maintains a single lock manager that resides in a single chosen site-say, Sj. All lock and unlock requests are made at site Sj. When a transaction needs to lock a data item, it sends a lock request to Si. The lock manager determines whether the lock can be granted immediately. If so, it sends a message to that effect to the site at which the lock request was initiated. Otherwise, the request is delayed until it can be granted; and at that time, a message is sent to the site at which the lock request was initiated. The transaction can read the data item from any one of the sites at which a replica of the data item resides. In the case of a write operation, all the sites where a replica of the data item resides must be involved in the writing.

The scheme has the following advantages:

• Simple implementation. This scheme requires two messages for handling

lock requests and one message for handling unlock requests.

• Simple deadlock handling.

The disadvantages of the scheme include the following:

• Bottleneck. The site Si becomes a bottleneck, since all requests must be

processed there.

• Vulnerability. If the site Si fails, the concurrency controller is lost. Either

processing must stop or a recovery scheme must be used. A compromise between these advantages and disadvantages can be achieved through a multiple-coordinator approach, in which the lockmanager function is distributed over several sites. Each lock manager administers the lock and unlock requests for a subset of the data items, and the lock managers reside in different sites. This distribution reduces the degree to which the coordinator is a bottleneck, but it complicates deadlock handling, since the lock and unlock requests are not made at a single site.

Related Questions

Navigate

• Browse (All)
• Browse R
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.