Distributed Transaction Models - Database Management System Video Lecture - Computer Science Engineering (CSE)

[Music]
aha
[Music]
they just need all of us to our bitch
away
[Music]
[Music]
[Music]
we have been considering transactions
and data executing on a single system
implicitly this is a assumption that we
have been making though we didn't
explicitly state that the underlining
assumption of the model transaction
models is that the transactions are
executing on the node and the data is
also fully resident on the same node
what we mean by node is a single
computer system on which there is an
operating system image and on which the
database is running and now the
transactions which a part of the
applications are all running on the same
system that is the assumption which we
are making when we are actually
explaining all the transaction models
now consider an example where for
example a reservation system where you
are sitting in Chennai and you are
trying to make a booking for a train
leaving out of Delhi which could mean
that you are actually trying to access
the database that is resident physically
on a computer system in Delhi sitting in
Chennai now it could mean several things
it could mean just that you are actually
trying to access the database through a
physical connectivity which could be a
telephone line a leased line some kind
of a connectivity between yours a
interface which could be just a display
interface to the system in Delhi which
means that it is still physically
working on the computer system that is
located in Delhi that could be one model
but this need not be the only model
which could be present when you work
with systems which are dispersed and
which are connected by no wide area
network
for a local area network or this what we
call as distributed systems when
computer systems are connected by by
network they could logically present a
single node kind of a abstraction for
the end user this is what we mean by
distributed systems
now when the data is distributed and the
transactions can be executed on
different nodes of the distributed
system we call the scenario as
distributed transactions that means we
no longer assuming that the transactions
execute on a single system computer
system but they could be executed on
different nodes of a distributed system
to explain the scenario what I will do
is I will take a very simple example of
a banking system and explain how the
scenario could look like let us say that
we have a bank in Chennai
SBI branch now I have also a branch in
let us say Mumbai is again SBI branch it
could be a different bank also and it is
possible that I have an account one here
and I have an account to here okay and I
am actually doing a funds transfer from
account one to account to which means
that I am going to do a debit here from
account one by let us say are 200 rupees
okay now it is possible for me to
actually credit the following thing on
to the other thing in K now this is the
data for account one okay is resident on
node one which is basically the Chennai
node okay and the account to which is
the other account data that is resident
or node 2 which is in Mumbai now this
this means that physically the data is
distributed in two locations one in a
Chennai branch and the other in a Mumbai
branch now if you assume that these two
are connected by some kind of a network
it does not really matter what is this
network but you can you can assume that
physically these two nodes are connected
by an underlining network okay this
network could be an ATM network okay or
it could be a fiber optic network or it
could be a variety of even a satellite
link could be present between these two
nodes so we are actually assuming that
some kind of connectivity exists between
these two nodes
which effectively means that the
information from one node to the other
node can be accessed or can be the data
from node 1 can be accessed sitting in
the other node or vice versa
it is possible so as opposed to this if
you are actually seeing a single case
where both account 1 and account 2 are
present on a single node let us say both
are present in Chennai this is what is
the case which we actually looked at
account 1 and account 2 and all that we
had was begin transaction and end
transaction as part of the transaction
here and all this will be executed in
the same branch of one system that means
physically this entire transaction is
executed on a single node now all the
things that we so far has been talking
belong to this scenario where both
account 1 and account 2 are present on a
single node and the entire transaction
here TR is executed on a single node so
TR is executed on node which is a single
node here and account 1 and account two
are present
on the node so there is no remote access
this TR does not access any remote
information both accounts are present on
the same node this is what ideally we
are talking about when we are talking
about one single node of a distributed
system as opposed to this if you
consider this particular case we are now
talking about account 1 and debiting
some 200 rupees from this account here
and account 2 which is present on a
different node and adding 200 rupees
here now imagine what can happen if
these are executed on two different
nodes now it is possible in the other
case a power has failed when the this
whole thing is proceeding in the single
system case it is possible that the
power could fail or other things could
happen when the transaction is executing
this is what we considered when we
consider the acid properties of the
transaction
now if the transaction is debiting and
creating from one account to the other
account you should ensure that the
properties are completely preserved the
acid properties are completely preserved
as far as the transaction is concerned
now in a single node when the power
fails the log records could be used to
make sure that the transaction will
always be in a consistent State for
example a part of the transaction is
executed that is credit part is executed
the debit part is not executed this can
be figured out from the log logs of the
transaction and either you can undo or
redo the transaction depending on the
state of the current transaction and the
log records that that that are preserved
now the scenario becomes quite
complicated
if you essentially look at a distributed
system now you are you imagine account
one debit is happening in one node
account two credit is happening in the
other node now it is possible that part
of the transaction is
executed part of the transaction is not
executed for various other reasons
firstly to knowing that they both got
executed itself is a is an important
issue this is like two friends separated
in two different locations trying to
ascertain whether the other friend
exactly has done what he is expecting
him to do it requires a few phone calls
and also making sure when the phone
rings the person is present so many
other issues get involved when people
are physically separated and they have
to coordinate and do some activity but
on the other hand if they are present in
the same node in the same room it
becomes lot more easier when when they
have to coordinate the minute they are
physically separated when the phone ring
somebody does not pick up does it mean
is is they're busy with something that
is why you didn't pick up the phone you
have to make some assumptions relating
to the behavior of the other node with
respect to your node and also if you put
up a telegram it could be a different
mode of communication
compared to ringing using a telephone
and trying to reach him so what are the
mode of communication between these two
systems okay between node 1 and node 2
what is the kind of communication
primitives that are present between
these two systems that also makes an
important requirement when you study
this kind of a model what we are trying
to say is if you assume that
transactions execute on multiple nodes
of the distributed system the whole
approach to concurrency control and
commit protocols takes an extra
dimension because you have to consider
here the possibilities of the
distributed system what can happen in
the distributed system node can fail
network can partition network can fail
which results in the system getting
partitioned for example if there is a
temporary network failure between node 1
and node 2
the note2 may not be reachable from node
one so all these issues become important
now the transactions have to take these
things into account and they have to
ensure the acid properties when these
things happen that is a most important
thing so we will actually consider this
model as a distributed transaction model
and we will study some concepts relating
to distributed transaction model
starting from this lecture now I will
explain at a very high level the
distributed transaction models and then
start going into more deeper details of
some of these transaction models to
explain the essential differences
between centralized systems database
systems and distributed database systems
with respect to the transaction models
we will take a very simple example and
illustrate with respect to that simple
example how exactly we can build a
distributed transaction model on top of
a distributed database system now
continuing the discussion that we had on
the credit debit transaction what we
will see essentially in the case of a
distributed transaction is a transaction
TR which was seen there will have now
two portions which is the debit portion
of the transaction and the credit
portion of the transaction
now debit portion of the transaction is
executing on a different account account
one which is on a node 1 which is
Chennai node this is resident on a
different node and this is resident on
node 2 now we call this credit and debit
to sub transactions of this root
transaction TR now if TR becomes the
root transaction
so there is a root transaction which is
the complete transaction
now what this root transaction will do
is it will actually spawn two agents
which are nothing but two sub
transactions agent one and agent - this
is agent one is actually a sub
transaction of the main transaction
agent two is another sub transaction -
okay now a single transaction is split
into two sub transactions so that these
two sub transactions are executed on two
different nodes of the system for
example the root is going to be on one
node agent one is going to be on another
node agent two is going to be on another
node now if agent one will execute only
the debit portion of the transaction and
agent two will execute only the credit
portion of the transaction that means it
will access account one here and make
sure in the account 200 rupees is
debited and here this will access
account two and make sure 200 is added
here now why doing this all the acid
properties have to be preserved as part
of this which means that as atomicity
concurrency isolation durability all
these acid properties independently have
to be preserved as part of this
particular exercise as you do not want
if the if the power goes off in the
middle of the transaction you do not
want to be unsure what really happened
to your account on a node 1 it should
preserve the property that 200 rupees
are deducted by this transaction
atomically know when it is accessing
this account other transactions are not
allowed to access this account when it
is modifying somebody is not allowed to
view the
before it is finished its computation
now after it finished executing it is
completely preserved on the database all
these in effect mean atomicity
concurrency isolation and durability
properties now to achieve this issue at
the highest level this is the model what
we have is the agent ok the root agent
spawning other agents okay agent one and
agent two on different nodes these agent
one and agent two are responsible for
the for executing the transactions on
the local node and together they form a
complete transaction for example
additionally now we have to worry about
if a to alone he is done and a one is
not done then again we have
inconsistency because a one is debit and
a one is debit and a two is credit so
you do not want only the debit being
done and not credit or vice versa you
want both have to be done simultaneously
okay when this is done this is also done
when this is not done that is also not
done that is what we mean by atomicity
either the whole thing is executed or
none of it is executed now to ensure
that this kind of an agreement is
reached between the various sub portions
or sub transactions that are executing
on different nodes we need what is
called an exercise a module that
actually does this okay which make sure
that the transaction properties which
includes the commit properties that
either all of them commit or none of
them commit okay the transaction begin
transaction end all these to preserve
this we will have an all nodes manager
running which is called the distributed
transaction manager this is the
responsibility of the
distributed transaction manager this DTM
stands for distribution distributed
transaction manager distributed
transaction manager
now the DTM on every node ensures that
the transaction properties are obtained
on each one of these nodes when they are
participating in the execution of the
transaction now each local execution
which needs to again maintain okay
transaction properties will come under
what we see as an l TM a TM is nothing
but the local transaction manager and if
you t l TM stands for local transaction
manager okay if you see exactly what we
said is in the earlier slide the debit
and credit here which are executed by
agent one and agent two needs to
preserve the transaction properties and
this is obtained by the acid prop by
preserving the acid properties for the
debit transaction and the credit problem
credit transaction this is insured for
the agent one and agent two by the l TM
l TM preserves the logs and all the
related things which are done in the
centralized database context the l TM
make sure all the things that are
executed by the agent or as per the acid
properties and that is what is achieved
by actually having the l TM on each of
these nodes to explain this is the model
this is the distributed transaction
model what you see is at the highest
level to just recap what we have been
telling along the complete transaction
no becomes a root transaction now as
part of the root transaction you will
have sub transactions which needs to be
started on different nodes of the
distributed system now here agent one
get started on node one and agent 2 get
started on node two agent one indicates
a sub transaction of the root
transaction agent two indicates the
other sub transaction of the root
transaction now for starting these
agents and also making sure that they
coordinate among themselves when they
are committing corresponding properties
are achieved by the distributed
transaction manager which is called the
DTM now the DTM is responsible for
preserving the transactional properties
across the various nodes now when the
agent starts on a local machine whatever
it gets executed in the local node it
preserved
by this local transaction manager that
means the local transaction manager is
responsible for ensuring that whatever
is executed in the local node obeys the
transactional properties and this is the
complete model of the transaction
distributed transaction model what we
are going to look at is we go to look at
with respect to this model how the
concurrency control and the commit
protocols are going to be executed in
this context and suddenly this becomes
you know this becomes little more
complicated than what we have earlier
studied in the centralized scenario for
example commit in the centralized
scenario is is just writing the logs and
making sure all the values modified by
the transaction are written back onto
the database and then if we are using
two-phase locking
then make sure that the locks are
released so that other transactions can
make use of now the data items modified
by the current transaction so commit
becomes a simple exercise of just
writing the logs and writing the
modified values back onto the database
now if you consider the distributed
scenario where there are multiple agents
running on multiple nodes of the
distributed system and the commit no
longer becomes that simple now you need
to worry about whether the node 1 and
node 2 for example for some reason no 2
does not want to commit each part of the
transaction you need to know and the
node 1 should roll back so you need some
kind of an agreement to be reached among
the various nodes before they actually
commit the values onto the database
system so this is basically called the
commit protocol commit protocol is a
more specialized protocol than an
general agreement problem now all that
you have to agree in the
case of commit protocols is either to
commit or abort there is no no other
agreement that that you try to reach in
the case of commit protocols because one
could mean I want to agree to commit my
part of the transaction zero could mean
that I would abort my part of the
transaction so all the nodes at the end
of the transaction that all the agents
involved in the distributed transaction
have to agree for a 1 or 0 depending on
a 1 actually means that they altogether
want to commit 0 means they do not want
to commit so we typically going to look
at these commit protocols and study
various commit protocols for achieving a
consensus this is the first part of the
distributed transaction model what kind
of commit protocols are existing and how
do they work with respect to various
scenarios like node failures network
failures partitions so we are going to
look at various scenarios what could
happen in the distributed system and
with respect to this how these commit
protocols really work that is going to
be the first part of the lecture is
going to focus on the commit protocols
we are going to essentially look at two
kinds of commit protocols one is the
two-phase commit protocol which as the
name suggests does it in two phases that
means it is a first phase in which the
participants are are prepared and then
the second phase actual commitment takes
place and that is what we mean by the
two-phase commit protocol and this
two-phase commit protocol naturally
integrates with the two phase locking
protocol that we have studied earlier in
the case of a centralized database
system so we will first study the
two-phase commit protocol and study the
extinction of the two-phase commit
protocol into what we see as the three
phase commit protocol
now the idea of this three phase commit
protocol is when sudden things happen in
the two-phase commit protocol which we
are going to see the protocol will get
blocked
that means the protocol will not be able
to proceed any further till the failure
recovery takes place in other words when
sudden kind of failures occur the
two-phase commit actually blocks the
protocol or block the system whereas by
actually modifying it into a three phase
commit protocol we will be able to avoid
the wait it actually becomes wait
free protocol in some sense when certain
kind of failures occur wait free
protocols in distributed systems are
extremely important because when
failures occur if the system is not
blocked because of a failure it is a
good property of the system because it
allows the system to naturally go
forward and not get blocked by a failure
so wait free protocols are very
interesting and important in distributed
systems now from two phase to three
phase commit protocol what you see is
you can avoid certain kinds of failures
and make the system resilient for these
kind of failures the system becomes more
robust under three phase commit protocol
as opposed to a two-phase commit
protocol we go to study first the
two-phase commit protocol in detail and
then going to study the three phase
commit protocol in the context of
distributed transactions to start with
in this particular class we are going to
focus on two-phase commit protocol and
study the two-phase commit protocol in
detail and see under what circumstances
two-phase commit protocol works
correctly now after looking at the
commit protocols they go to look at
concurrency control protocols in the
context of distributed transactions
is going to be later part of the talk we
focus on the concurrency control
mechanisms as applied to the distributed
transaction systems now the rest of the
lecture from this point will concentrate
on the two-phase commit protocol and we
will try to explain in detail the
two-phase commit protocol now let us
look at what kind of a scenario will be
required when you actually looking at
the two-phase commit protocol now to
explain what really commit protocol
means we have actually taken a root
transaction which actually started
executing on this is basically the begin
transaction this this is the begin
transaction now I have basically the
agent 1 which is the debit portion of
the transaction this is the debit on
node 1 debit on node 1 this is basically
the sub transaction of agent 1 agent 2
is the credit on node 2 this is
particularly operating on account 1 and
this is operating on account to assume
that at some point of time this is the
end transaction now when the actual
agent 1 and agent 2 are started on
different nodes of the distributed
system and they start executing on these
two different nodes at some point of
time when I reach the end of the
transaction I am going to look at this
part okay and at this point of time I
have to decide whether I will be
committing my transaction right I have
reached this point now and when I reach
this point I need to understand off
whether agent 1 and a
- are willing to now go with writing or
Renault doing their debit and credit
completely for various reasons it is
possible that agent one or agent two may
not be willing to complete their part of
the transaction one reason could be
account one is not present on node one
or the account has been closed for
various reasons which means that it
finds that account one is not present on
its node which means the debit cannot
proceed logically any further in which
case the agent one whatever agent two
wants to do agent one will say I am
going to abort my part of the
transaction because I cannot complete my
part of the deal I cannot finish the
debit transaction on my node because
account one has been closed the other
case is account one does not have
sufficient funds let us say it has no
balance and you are trying to with about
two hundred rupees from the account when
there is no balance in the account again
agent one is going to say look I am NOT
going to commit my part of the
transaction because there is no way I
can commit this transaction so in all
these cases both these nodes have to
agree both agent one and agent 2 have to
agree to commit their transactions for
this whole thing to go through otherwise
there is no point trying to have one
part of the transaction executed and the
other part not being executed now to
ascertain this this commit protocol gets
started
ideally at the end transaction for
example when you reach the end of the
transaction you have to actually now
start this commit protocol to ascertain
whether this whole transaction can be
committed or not which means that it is
at this point of time all the agents
involved in the transaction have to
participate in this commit protocol to
ensure whether they are committing the
transaction or not committing the
transaction okay
that is the part of the commit protocol
now let me explain this by taking
what we actually call as a coordinator
of the transaction which means that we
will first fix a coordinator for the
commit protocol okay which means that
there is one single load there is a node
in the distributed system that is going
to act as a coordinator for the commit
protocol and ideally this is the one
where the transaction has been submitted
okay
which will try to coordinate transaction
has been
okay
that is what we mean by coordinator now
all the agents where this transaction is
being executed we call them actually
participants they are all participating
in the commit protocol so they are
called participants so all agents where
the sub transaction is executed is
called the participants where the sub
transaction is executed is called the
participants so we have actually two
things in the two-phase commit one the
co first the coordinator and a number of
participants now the responsibility of
the coordinator is to initiate the
commit protocol and make sure some
response from all the participants and
based on that the coordinator has to
take a decision again inform all the
participants and properly terminate the
commit protocol at the end of the
execution so this is what we call as a
coordinator each participant as a
responsibility for its own local
transaction it should when it is
replying on behalf of the local agent it
should ensure that certain things are
done by the local agent before the
participant replies back to the
coordinator with a reply now we are
going to look at the full detail what
are the steps that will be done by the
coordinator and what are the steps that
will be done by the participant in the
case of two phase commit protocol now
what we do in the case of two phase
commit protocol is the coordinator
initiates the commit protocol at the end
of the transaction he initiates the
commit protocol
by what we mean by initiating is he
sends certain messages to various
participants and make sure he gets some
response from these participants when is
insuring when he is actually executing
this commit protocol now this is a
responsibility of the coordinator to
start the commit protocol at the end of
the transaction this he does by sending
what is called a prepare message to all
the prepared message this message is a
sub special message which is called the
prepared message okay he prepares the
participants for this okay prepare
message is sent to all the participants
now after sending the prepare message
the coordinator enters what we call as a
wait state because he still now not
decided on the final outcome of this
particular wait state till all replies
are received or if some of the this is
where basically the problem comes if the
if there is a problem in terms of some
participants not responding because
there is a failure of either the network
or the node then they are not going to
respond if they do not respond what is
going to happen to the coordinator so
the coordinator basically puts a or a
timeout period he actually starts a
timeout period immediately after sending
the prepare message now you will wait
only for this timeout period and if the
replies does not come within this
timeout period is going to decide
unilaterally now based on what reply she
has got if he has not got the replies
you will ensure that that I know based
on this he will make a decision which
actually make sure that even in that
case he can still make a decision but
probably he might make a decision on the
negative side saying that I will abort
which is a safer decision to make
because when the participant comes at a
later point of time it is always
possible to ask the participant to abort
rather than to commit so you will wait
for a timeout period and after the
timeout period is going to make a
decision relating to whether he should
be committing or abort okay always when
the timeout has reached and replies have
not come is going to make a decision
relating to abort of the transaction
rather than commit of the transaction
now as far as the participant is
concerned
participant actually decides now waits
for the commit protocol that means or to
start with is in an undecided state wait
for prepare message okay from the
coordinator now when he gets the prepare
message from the coordinator okay now we
have to reply now the two things which
the participant can do participant
actually can reply with a ready message
what the ready message means is that the
participant is willing to commit his
part of the transaction that is what
actually means by the ready message the
ready message indicates that the
participant is willing to commit his
transaction that means he has executed
successfully his part of the transaction
and he is willing to actually commit his
sub transaction that is what it means by
the ready message now before sending the
ready message if he is willing and
before sending this ready message he
needs to actually ensure that before
sending the ready message what should he
be doing he should be ensuring that all
the logs are written because if he does
not write the logs and it applies with a
ready message the coordinator assumes
that whatever may happen later the
participant is willing to go with the
commitment of the transaction so
tomorrow you cannot come back and say
look I am NOT going to commit once you
are replied with a ready message you are
committing yourself to commit this
transaction so it is important for you
to write all the logs and you are also
if you are using a locking protocol we
are not going to release the locks till
you know the decision of the coordinator
because if the coordinator now says
please commit you
to write all the values of onto the
database and then only release your logs
so before sending the ready message the
participant should write all the
required logs participant writes the
required logs now if you carefully
observe all this writing the logs
preserving all the different properties
of the transactions is achieved by the
local transaction manager ATM ensures
that all this local transaction
properties are maintained using the l TM
now the participant once it makes a
ready message the coordinator can now
decide if he receives all the reading
messages can now we can decide what
needs to be done up to this point we
call this is phase 1 that means phase 1
is preparing the participants for commit
okay we are preparing this is actually
prepare phase you are actually preparing
the participants for committing only in
the next phase phase 2 you actually
commit so there are two separate phases
that is why it is called a two-phase
commit protocol in the first phase we
are preparing all the participants for
committing in the second phase you are
actually committing the transaction okay
now it is possible in phase one you
reply back for some reason the
participant is not willing to commit
because as we explained earlier there is
no sufficient funds all these could be
reasons why the participant may not be
willing to commit his transaction in all
these cases what the participant does is
he actually sends an abort answer
message okay which means that e sense
saying that I am
aborting is answered for prepare is
abort answer message when a participant
is actually giving an abort answer
message participant is not willing to
commit his part of the transaction
participant is not willing to commit
okay
not willing to commit when
coordinator receives this abort answer
message you will be forced to take only
on the second phase we are going to take
the commit decision so Phase two
once the coordinator enters phase two is
actually making the decision on commit
is deciding not on a decision on
committee is made here now what are the
different decisions
it is possible within the timeout period
coordinator received all the coordinator
received all ready messages from all the
participants
already messages then
now if the coordinator in this
particular case we take a decision to
commit the transaction that is obvious
because all the participants in the
transaction are willing to all the
agents in the transaction are willing to
commit their part of the sub transaction
and hence is logical for the coordinator
to take the decision to commit the
entire transaction but before actually
taking the commit decision okay before
sending the commit message the agent the
coordinator has to write his decision on
a stable storage so that whatever may
happen later the coordinator can recover
back and see what is the decision that
was made by him with respect to this
particular transaction that is the
logical thing which he does so we expect
that in this particular case coordinator
received already messages commit
decision is taken commit message is sent
to commit message is sent
is sent to all participants okay before
sending the commit message before
sending these are the steps that the
coordinator has to follow before sending
the commit message he needs to actually
write the commit log a commit message he
needs to write a stable log is written a
stable log is written this is very
important because whatever may happen to
the coordinator you should be able to
now tell the rest of the participants at
a later point of time what is the
decision that was taken on this
particular our transaction okay when the
participant receives okay now at the
second phase phase two when the
participant receives participant
receives the commit message receives see
a message commit message okay II the
transaction is committed and an
acknowledgement is sent to the
transaction is committed committed and
an ACK sent acknowledgement nerve is
sent again ACK is sent he sent to the
coordinator to the coordinator now the
coordinator when he receives in the
second phase all the acknowledgments the
coordinator on receiving the coordinator
on receiving on deceiving all a/c case
that is acknowledgments will write
complete wrong will write the complete
log now this is at this point of time
the transaction is completed and it can
be closed successfully by the
coordinator now there could be various
cases in between this we are talking
about only a successful completion of
the transaction by the coordinator as is
proceeding from one phase to the other
phase to recap what what we have done
phase one this is actually in the phase
one coordinator initiates the commit
protocol and here he actually sends a
prepare message is sent to all the
participants this is in the phase one
first action of the coordinator and the
enters into a wait state for a timeout
period for the replies from all the
participants now the participant who is
waiting for the prepare message can
actually respond with a ready message
before sending the ready message the
participant makes sure he writes all the
stable logs and enters into enough a
wait state for the decision of the
coordinator now the coordinator after
this point enters the phase 2 the phase
2 is entered by the coordinator ok when
he receives all the replies from the
know all the nudity messages from the
participants or a timeout period has
arrived now in either case he takes a
decision if all the messages are
received
ready messages are received he commits
the transaction writes the commit log
and sends the commit message to all the
participants
now the participants in the second phase
when they receive the commit message
they actually write all the the
transaction is committed committed
and an acknowledgement is sent back to
the coordinator so that now you can
write the complete log and close the
transaction now it is possible that in
the first phase we didn't discuss the
case where it is possible for the
participant to reply with an abort
message okay now when the participant
replies with an abort message or
coordinator waits for a timeout period
in either of these cases the coordinator
is going to take a abort decision and
this will be communicated to all the
participants and when they receive the
abort decision the participants are
going to abort the transaction this is
what actually happens with the two-phase
commit now before we actually go into
details of looking at what are the
different things that can happen one of
the different failure scenarios that can
be present in this in this case and how
the two-phase protocol is resilient to
that kind of failures we will try first
looking at what was the state transition
diagram for the coordinator and the
participant that explains this whole
scenario in a lot more detail and after
that we are going to look at more
details on how the two-phase commit
protocol is resilient to certain kind of
failures when the commit protocol is
executed now to just explain this what
we are going to take is this is actually
the coordinators state transition
diagram coordinators state transition
diagram I am writing the state diagram
of the coordinator to start with just to
start with the coordinator is basically
in the initial state and from the
initial state what the coordinator does
is he actually sends prepare message to
all
participants so this actually we will
have some level of undecided state this
is a state where they a decision was not
taken by the he enters this wait state
which is the undecided state now this is
basically the prepare message is sent by
the coordinator and is waiting for the
decisions from all the now it is
possible that actually he waits from
this state it is possible for the
coordinator from this undecided state
that he received all the ready messages
which is what we have actually seen okay
now when he gets all the ready messages
is going to take when the input to the
coordinator is ready messages all the
ready messages have been sent to the
coordinator then you are going to get a
commit command commit message from the
coordinator and the state in which
actually the coordinator reaches in this
case is the commit state now it is
possible that the coordinator actually
okay got abort answer message okay from
the participants when he actually got an
abort answer message and he is going to
take an abort command message that means
is going to send an abort command to all
the participants and that is typically
when an abort decision is taken by the
coordinator now it is possible that when
from the initial state the coordinator
can reach the abort decision if there
are no sufficient replies that is a
timeout period when a timeout period is
reached okay where time out period is
reached it is possible for the actually
by sending the prepared message gets to
the undecided state so strictly speaking
this arrow should come from the
from the undecided stage here which
means that this is the state from which
this arrow will come where there is a
timeout period and after the timeout
period the coordinator is going to take
an abort command message that means he
waits for a timeout period and after the
timeout period he actually takes the
decision to abort the message now if you
look at the participants state
transition diagram it looks something
like this to start with actually the
participant is an initial State
now when he receives the participants
receives the prepare message and the
answers with a ready message then he
basically basically enters the state of
the ready state here now from the ready
state it is possible for the participant
to reach when he reach many many
receives the command message he could be
receiving the he could be state could be
sending an acknowledgement message and
could be reaching the commit state if he
actually receives an abort message
the abort command message again you will
acknowledge but he will reach the abort
state okay it is possible for the
participant from the initial stage
itself by actually responding with an
abort answer message it could be
reaching this state he actually sends an
abort answer message with which he
actually reaches the abort message this
sort of summarizes what we are doing now
with the two-phase commit protocol what
we are going to do in the next class is
take these two transition diagrams and
then explain how the two-phase commit
protocol is resilient for failures
[Music]
you