Deadlock Prevention Mechanism

for Distributed Transaction

Management

By: Nileshwari Desai

Roll No: A 216

Contents

• Introduction

• Background

• Proposed design

• Improvement

• Related work

• Conclusion

• Future work

• References

Introduction

• Massive increase in business services requirements have necessitated the use of distributed transactions. Many enterprises use SOA as their basic business architecture, such as stock deal, bank services and on-line ticket booking system.

• With the success of SOA, many large-scale information systems have been set up to process the business transaction services simultaneously, especially in grid environments.

• Grid transaction principles were brought forward to build dynamic, distributed and scalable data access and management for e-business applications.

• In fact, many current distributed applications integrate heterogeneous databases in one system by using JTA and the like technologies to provide distributed or cloud services. With grid transaction involved, new services on different stations can be easily integrated into existing applications.

Proposal by the author

• Providing efficient replica mechanism to support for locking services of preventing inner deadlock in local transactions.

• Designing a timestamps based victim selection criteria that can break a deadlock cycle when global deadlock is detected.

• Designing an intelligent resource manager to detect inner transactions collisions or global transaction deadlock and allocate appropriate locks for each transaction.

Background

Deadlock

Local deadlock Global

deadlock

Distributed transaction

coordination algorithm

Flow/ Phases

A). Distributed Transaction

Coordination Algorithm • Most commercially available transaction services

support only a flat distributed transaction model. This is a top-level transaction and has the fundamental property of a transaction: atomicity, consistency, isolation and durability. Usually, an atomic transaction is managed by a transaction manager(TM) with a resource manager (RM) which is responsible for allocating resources. A RM can be shared by many TMs to cooperate in distributed environment.

• For distributed transactions, we should expand the scope to join several resource managers and need to control all the resources involved in a nested transaction.

Phases

• First phase: all participants (sub-transaction) receive instruction from the transaction coordinator to prepare to commit. If a given resource manager can commit its work, it votes agree to the coordinator saying that it's prepared. If this resource manager cannot commit, it replies that it is unable to commit and rolls back its work.

• Second phase: the transaction manager sends a commit acknowledgment to all participants if all of them reach prepared state. Otherwise it tells all of them to roll back. Then all the resource managers commit or roll back as directed and return status to the transaction manager.

This simplified two-phase commit protocol flow ensures that every participant in one execution takes the same action (everybody commits or everybody rolls back), so the resource updates are either committed together or rolled back together.

B). Deadlock Scenarios

• In distributed especially grid environment, commercial transaction services are often deployed on different sites. Each transaction, whatever local or global, may access many different resources at the same time. In this paper, the author calls local transactions for only one big nested transaction with many sub-transactions.

• In contrast, several local transactions, each supposed to be independent, are called global transactions.

Local deadlock

• To support a two -phase commit transaction, the resource managers must hold the requested resources between phase one and phase two, otherwise other applications may grant access to these resources and lead to inconsistency if they update the resources at the same time. Resource manager often takes lock to hold the resources for the request from some transaction manager until the second phase receiving instructions to commit or roll back, and then release its lock.

• After the first stage, the transaction coordinator waits for all the sub-transactions (participants) to vote their approval (prepared or not). It must collect all of their opinions to make the final decision. Under this condition, if two or more participants request for the same resources, a guaranteed deadlock is inevitable.

Simple dead lock

Global deadlock

Extended local deadlock

THE PROPOSED DESIGN

• how to prevent deadlock for local transactions.

• deadlock prevention and victim selection mechanisms for global transactions

A). Replica Based Local Deadlock

Prevention

• The basic idea is to produce a replication of the resource when more than one participants request it. So we need an intelligent resource manager which is responsible for allocating resources for every applicant.

• Every transaction has a unique transaction id, including sub-transactions. When a sub-transaction manager receives instruction from parent transaction manager/coordinator, it keeps the root transaction id passed by its parent and produces its own sub-id. So every participant knows the root id and we can distinguish if two sub-transactions belong to the same nested transaction. If two participants have the same root id, we don't care which level they are on.

Replica based mechanism for

guaranteed deadlock

B). Timestamps Based Restart Policy

for Global Deadlock Prevention

• Standard technology of deadlock avoidance

expects sequentially resource access. For some resources, system could declare the most amount of requirements in advance. This is a pessimistic static allocation algorithm that needs to exploit prior knowledge of transaction access patterns. If deadlock is allowed (e.g. it's rare to happen), detection and resolution are the main issues we should consider.

Global deadlock resolution

The deadlock prevention steps:

Step 1. Transaction manager receives user's task and produces a global unique root transaction id. This id can be a function of current time to distinguish which transaction starts earlier. TM divides the task into sub-transactions and distributes them onto different sites which host specified transaction service.

Step 2. Each participant receives pre-check instruction and begins to try to get all the needed resources from resource manager.

Step 3. If the coordinator receives positive checked messages from all participants, it decides to send a request-to-prepare message to each of them, and the two-phase commit begins. Otherwise, it should be regarded as not meeting its prerequisite to continue.

Live lock

C). Improvement

• Though a pre-check phase can be added to the two-phase commit

protocol, especially for long transactions which do not need to waste too long for prepared sub-transactions if some of them fail at pre-check phase, we could optimize it for some real-time or basic atomic transactions. The base idea is to piggy back this phase onto the prepare phase to reduce communication overhead.

• For every participants, if it cannot obtain the lock of required resources, it will response not prepared message to the coordinator directly. On the other hand, the participants start to prepare their work of transaction execution, though they may be disrupted at any time. For they are not committed, aborting themselves at any time has no effect on the resources. But this will cause another a little change that resource manager may need to wait until other transaction aborts if resource request conflict happens.

Related work

• Several researchers have proposed centralized and distributed deadlock detection algorithm. Others outlined the key differences between the local deadlock detection utilizing external detector node and distributed deadlock detection by transmitting deadlock information from one site to another. In the current design the author leverage the benefits of resource manager for distributed transaction to control concurrently resource access to avoid deadlocks. It is particularly useful for independent business services which have prior knowledge of what resources they will access.

• Yi-Min Wang et. al. , have proposed guaranteed deadlock recovery based on run-time dependency graph and incorporated it into distributed deadlock detection algorithm, their design can only support message-passing applications. In the proposed work the author provides efficient prevention mechanism with precious a little of overhead for different types of transaction.

Conclusion

• The massive increase in SaaS based business service model requirements has necessitated the use of highly efficient distributed transaction processing. In this paper, the author has presented a novel distributed deadlock prevention mechanism utilizing the prior knowledge of required resources by extending standard two-phase commit protocol.

• The approach solves the guaranteed deadlock perfectly for local nested transactions.

• Further, it is also demonstrated that the approach used in distributed transaction services is totally free of deadlock and there isn't any more overhead after a little optimization is applied. Since the design highly depends on the resource manager to distinguish different resource requests, it should be much strong to communicate with transaction managers and needs to keep massive resource status under highly concurrent condition.

Future work

• One can plan to extend the designs to include more precisely control of different types of locks, such as shared locks and exclusive locks. Shared locks should deserve special treatment by resource manager but need more consistency consideration.

• In addition, transaction recovery is not discussed in this paper though it may cause other potential deadlocks. Three-phase commit protocol is an example that one can probe deeply into about its traditional locking mechanisms.

References

[1]. Xinfeng Ye, John A. Keane, “A distributed transaction management scheme for multi database”, University of Auckland.

[2]. Lin Lou, Feilong Tang, Ilsun You, Minyi Guo, Yao Sen, “An effective deadlock prevention mechansim for distributed transaction management”, Korean bible university, Hong kong.

[3]. David Taniar, “high performance parallel database processing and grid databases”