3. 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.
4. 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.
6. 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.
7. 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.
8. 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.
9. 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.
13. THE PROPOSED DESIGN
• how to prevent deadlock for local transactions.
• deadlock prevention and victim selection
mechanisms for global transactions
14. 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.
16. 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.
18. 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.
20. 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.
21. 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.
22. 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.
23. 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.
24. 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”
