Basic 2-Phase and 3-phase commit protocol - Database Management System

oh no they just mean all of us away
[Music]
[Music]
[Music]
in the last lecture we have just looked
at the basic two-phase commit protocol
we just stopped at the point where we
just had the basic protocol and how it
works actually two parts there one part
is the participant protocol and the
other is the coordinator protocol how
the coordinator protocol is working is
the coordinators starts with sending a
paired message and once he sends a
prepared message from the initial state
he actually reaches the
state where he is now undecided so the
prepared message is sent to all the
participants once the prepare message
has been received by the participants
they will reply back with a ready
message to the coordinator if the
coordinator actually receives all the
ready messages then he will take the
commit and he will send the commit
message then the coordinator will reach
the commit state and if
he receives any of the participant
actually says he wants to abort that
means for the prepared message he gives
an abort answer message then you are
going to actually take an abort command
message and this state actually the
coordinator reaches the abort State it
is also possible for the coordinator to
reach the abort State if it times out
that means he does not receive the
message from the participant then one of
the participants has failed since one of
the participants has failed you have
bound to actually take in about message
right this is the basic part of the
coordinator as far as a participant is
concerned that is each participant site
for the two-phase commit is concerned
each participant starts with an initial
state now he is going to get a prepare
message in response to the prepare
message he can basically give a ready
message now when he gives the ready
message is in the basically the ready
state when he is in the ready State now
wait for the coordinators decision if
the coordinator actually gives the abort
command message then you are going to
acknowledge and then reach the bought
state which even after you actually
replied with a ready message it is
possible the coordinator can still take
a aboard decision because in that
particular case the other participants
may not have replied back unless he gets
all the ready messages he can't commit
the transaction right now in the other
case
all the participants no replied with
ready message the coordinator is going
to send the commit message in which case
the participant actually commits and
then sends an acknowledgement that means
as written all the values onto the
database this is the basic two-phase
commit protocol that we have seen in the
last lecture and where we have just
stopped is just explained this protocol
and then said that what happens in terms
of different failure scenarios we
thought we will look at it in the next
class that is way we stopped in the last
lecture
now there are several things that can
happen in this basic protocol for
example coordinator can fail in the
first phase or the second phase
participant can fail in the first phase
of the second phase Network could fail
which means that it is possible for the
various nodes to get partitioned there
are some nodes in one partition some
nodes in the other partition so all
these are possible scenarios as far as
this protocol is concerned now one of
the things we can located is what are
the cases where this protocol is
resilient which means that which are the
failure scenarios where this will still
work correctly okay now let us first
take the case where and all so we are
going to look at different cases of
failures
now the first kind of a failure is a
participant fails in phase one okay what
happens if the participant fails in in
the two-phase commit we are talking
about the first phase okay
now what happens in this case is the
coordinator will timeout and then once
the coordinator times out is going to
take the decision of aborting or sending
an abort message here for example here
the coordinator is going to timeout and
then it is going to in that response is
going to take an abort message about
command message the minute actually one
of the participants has not replied okay
so I think that so in this particular
case the coordinator will timeout and
then take a aboard decision coordinator
will time out as a result is going to
take an abort command message okay that
is what is going to happen when
participant fails
so obviously two-phase commit is Lesley
and for participant failures in the
first phase now what happens if the
participant fails in the second phase of
the
okay participant fails
in the second phase that means in the
first phase the participant has replied
with a ready message which means that he
actually replied with a ready message
and now he is waiting for the
coordinators decision coordinator can
take either a aboard decision or a
commit decision now if you say that the
coordinator has taken an aboard decision
or commit decision you have to after
recovery you have to check with the
coordinator and accordingly you have to
do as far as you are concerned you have
replied with a ready message that means
you actually now written all the logs
and you cannot release any of your logs
or any of the resources till such time
you know the decision of the coordinator
right so in this particular case you are
going to wait for the decision of the
wait for the decision now since you are
waiting for the decision since you fail
waiting for the decision all that you
have to do is after recovery that means
after you recover from failure after
recovery the participant should check
with the coordinator participant checks
with the coordinator for the decision
what happened about this transaction he
has to check with the coordinator and
accordingly he has to terminate the
transaction that means based on what the
coordinator tells now coordinator need
not wait for this participant because it
is already replied with a ready message
so in this particular case the
coordinator is free to choose an hour
decision depending on ready message or
if he gets all the ready messages then
you can take the decision to commit the
message commit the transaction in which
case a commit decision would have been
taken so that participant has to find
out now what happened to this
transaction and he has to do accordingly
one of the things is here neither other
participants will be blocked because of
this participant failure nor the
coordinator will be blocked all that the
coordinator has to do is write the
decision of this and when the
participant comes back he has to tell
the participant about this decision and
the when she gets acknowledgement from
the participant is going to write the
final log on this transaction saying
that it has been successfully completed
plea that is a thing that needs to be
done in this particular case now it is
possible also for the failures to happen
for the coordinator at different phases
and they also possible that both
coordinator and participants can also
fail need not be just failures of
participants alone or coordinator alone
but right now what we looked at it is
what happens if the participant fails
one or more participants fail in the
first phase and the second phase so if
you want to look at what happens to the
coordinator failures
suddenly you have to now understand in
which phase the coordinator has actually
failed again we can see the case wave
coordinator failed in the first phase
if the coordinator actually failed in
the first phase that means he sent the
prepare message and after that he has
failed he is not actually taking any
decision on this transaction and then he
failed before the ready messages have
actually arrived at the coordinator so
coordinator has not reached a decision
but then after sending the prepared
message he failed the coordinator has
failed now the way to recover from this
is simple all that the participants have
to do is they have to elect a new
coordinator and then restart the
protocol that means the new coordinator
will now send the prepare message and
then correspondingly he will take the
decision about the transaction by
running the two-phase commit protocol
again so in this particular case a new
coordinator is elected assuming that
there are no failures new coordinator is
elected here and then the transaction is
so he started that the two-phase commit
of the transaction is restarted that
protocol and then based on that the
commit protocol will be executed based
on this one of the assumptions that we
will be making here is that all the
participants are live they are not dead
but then if they're if it is not the
case also what will happen is the new
coordinator will be elected and he will
time out when he starts a protocol so
you will make an abort decision okay so
in that sense the protocol becomes
reentrant that means any number of times
any number of fails failures occur for
example you elected a new coordinator
now that coordinator fails again in
first phase then you are going to again
have the election algorithm to elect a
new coordinator okay
this basically protocol is very
pull now in the other case if the
coordinator actually fails in the second
phase this is an interesting problem
actually the very fact that you are
saying that the coordinator actually
failed in the second phase means that he
has taken a decision right now it means
that decision has been taken decision of
aborting or committing has been taken
okay now one of the conditions that can
happen here is has this decision be
known by other participants okay which
we can say now there is a case where at
least one participant knows this
decision of the coordinator before he
failed okay so the scenario one is here
is one of the participants received one
of the live participants which means
that he is actually life and then he
actually received this decision of the
coordinator live participants okay
received the decision which actually
means that
all that you need to do in this
particular case is since the decision of
the coordinator is known the same
decision can be conveyed to everybody so
if it is a commit decision everybody
will commit if it is an aboard decision
everybody will abort okay right so it is
a very simple case where the decision of
the coordinator is already known the
coordinator fails some participants
didn't receive this decision all that
they have to do now is find out if any
of the other participants have received
the decision of the coordinator if they
have then it becomes a simple scenario
where that decision can be implemented
by the other participants also in this
particular case it becomes non blocking
that means nobody is actually blocked
okay this is very important you are not
now waiting for somebody to recover back
okay right for example if the shooting
is happening and our recording person
decides to go out for a tea or something
then we are all blocked till such time
he comes back you know that is a
blocking protocol you do not want things
to be blocked you want actually even if
he goes and he puts it on an automatic
mode and goes off then we are not
blocked we can continue our job okay so
in a similar way even if one of the
coordinators fails okay and it still
none of the participant need to wait to
wait for this coordinator to recover
back from that failure it is a very nice
thing and it is a very simple case you
know that is how we want to actually
model our protocol we do not want any
other participant to suffer because of
this failure suffer means yes to Vietnam
is and you do not know when that
recovery is going to happen so you get
indefinitely blocked if such a thing
happens so one of the all the cases we
have seen so far two-phase commit
protocol is non-blocking it does not
block anybody okay now there is a
interesting case that is going to come
now
where we can see the case where okay the
scenario - where the coordinator fail
none of the live participants know about
the decision of the coordinator okay but
again they're going to be two sub cases
here okay now we can say
decision of the coordinator is not known
okay coordinator is not known in this
case it is possible that you know all
the participants are life that means
there is no other participant failure
okay that means only coordinator has
failed the decision of the coordinator
is not known but all the okay the case
where this is
there is only first case this is not the
second case okay first case where all
the participants are life that means
there is no participant failure all the
participants of life okay in this
particular case since all the
participants are live a simple thing
they can do is they can restart the
two-phase commit protocol by electing a
new coordinator in this particular case
you will elect a new coordinator and
restart the
okay and restart the two-phase commit
protocol okay
you're going to see is the case where if
you say that the two-phase commit you
know the the participant also failed
along with the coordinator okay right so
there is a not only a coordinator
failure but there is a participant
failure which means that
now the rest of the people the
interesting case is here imagine that
the coordinator took a decision of
committing and there is known only to
this participant and he actually wrote
all the values on the of the database
and then he actually a failed okay now
if the remaining participants now elect
a leader coordinator and then terminate
the protocol it might contradict if the
earlier coordinator already taken a
decision and that is known to this
participant there is no way to recover
back from this so basically this is the
case where all the other participants in
this particular case all the live
participants will be blocked okay all
the live participants are blocked till
such time the coordinator recovers you
cannot do now anything except wait for
the coordinator to recover wait for
coordinator to recover okay
now often a coordinated failure also
means a participant failure because the
transaction where it is started normally
coordinator is one of the participant
sites for example if you basically look
at how the transactions are started one
of the sub transactions where the you
know where it is getting executed you
will also take up the responsibility of
being a coordinator normally coordinator
failure will be equivalent to a
participant failure and that is a
scenario where two-phase commit will not
be able to recover back and this is an
important case normally you do not have
a coordinator failure a coordinator
failure normally means a participant
failure the only thing is if it is
failed in the first phase then you are
you're a bit lucky because in that
particular case the remaining
participants can elect a new coordinator
and make a decision but if actually
failed in the second phase phase two
after actually sending the ready message
the you discover that the coordinators
actually failed you will be in trouble
because you won't know whether the
coordinator has taken a decision or not
taking a decision so that is the case
where the participant is forced to wait
till the coordinator the covers back
from this failure okay now having
explained this
what we are going to see is how this
protocol gets modified now to also allow
the protocol to recover in the case
where the coordinator fails in the
second phase along with the participant
and that modification is what we see as
a three phase commit protocol what the
three phase commit protocol does is
intuitively to understand what the three
phase commit protocol does is
when the coordinator actually failed you
won't know what is the state in a state
in which the coordinator is and this is
very important in distributed systems
this is a typical problem that you will
face in distributed systems you need to
know the state of the other node when
things have actually failed or when the
system crashed if you know the state of
the system it is easy for you to recover
back but now if you do not know the
state of the system then you are in
trouble in terms of recovery back from
the recover recovering from that
particular failure now in this
particular case when the coordinator
actually failed you won't know whether
it has taken a commit decision or an
abort decision now what you want to
decide now is or want to see is what is
the state in which it is to actually get
out of this ambiguity you are
introducing a three phase that means the
coordinator will not directly get into
the phase of committing if you carefully
observe the problem is in terms of
moving coordinator moving directly when
it gets a ready message into the commit
state if you actually record in between
a state where the coordinator says that
now I have received all the ready
messages now I am prepared to commit
okay you still not committed but then
now you introduce a prepared to commit
state for the coordinator which means
that now you know whether the
coordinator has reached a prepared to
commit state or not if he has not
reached the prepared to commit state
then no harm done because he failed in
the second phase but then only in the
third phase actual commitment would have
taken place right so basically you need
to know the state of the coordinator
when you actually died or when he failed
no so in that to remove that ambiguity
you going to introduce now a third phase
and that is where basically you get
three phase commit protocol what we are
going to do now is we are going to see
how this gets modified for the three
phase commit protocol or how the three
phase commit protocol works and then
also look at what kind of failure
scenarios the three phase commit
protocol can tolerate or it is resilient
to what kind of failures now what we are
going to do is for both the participant
as well as for the coordinator will
introduce a new state a new state where
they have to first get into the before
commit state or prepared to commit state
before they actually commit they can't
directly get into the commit state from
the ready state now the coordinator part
is going to look something like this now
I will start with an initial state and
now as usual I will send a prepare
message to all the sides then I
basically reach the undecided state here
because I still not decided on the state
but now if I basically get all the ready
messages then I will actually enter what
I call as a before commit state I still
not committed
so I basically reach a before commit
state here now once I reach this state
before commit state and I receive
acknowledgments from all the
participants then I take the commit
message that means I get an okay from
all the participants then I will issue
the commit message and then I reach the
commit state after receiving okay from
all the participants now it is possible
for me for various reasons to move from
before commit state to an abort state if
I do not receive okay from all the sides
I can still end up in a abort state as
usual I can also come to the abort state
if there is an abort acknowledgement
message on
a message from one of the participants
then in response to this as usual I will
take the abort command message it is
also possible to a time-out message I
might reach the abort command message
okay now this is the diagram for the
coordinator state diagram for the
coordinator looks something like this
okay the participants state diagram in
the three phase commit will look
something like this the participant will
be initially in the initial State
when it receives the prepared message it
will
reach the ready state
if it is willing to commit the
transaction so in that case the
participant will reach the ready state
in case it is not willing to commit the
message then it will answer with an
abort answer message and we'll reach the
abort State
from the ready state also is possible
for the participant to reach the abort
state if it receives an abort command
from the coordinator which case is
possible for the you know for the
participant to actually reach this state
if there is an abort command message and
then the participant
reaches that state through the very
state if the other participants are not
willing to commit the coordinator can
take the
decision to abort the transaction in
which case the participant will move
from the ready state to the abort state
if all the participants
are ready to commit the transaction
which means that all of them have
actually responded with a very message
then it is possible for the coordinator
to take a commit decision in which case
in the three phase commit he will
initially enter the state called the
prepared to commit state which means
that he will send the prepare to commit
message to the participant when the
participant receives the prepared to
commit message he will reach the
prepared to commit state
now when he reaches the prepared to
commit state is still not committed the
transaction is waiting for the final
decision of the coordinator when the
coordinator receives ok for all the
prepared to commit messages then he will
actually issue the commit message that
is a commit to instruction in which case
the participant will reach the commit
state here this additional state is
needed because it is possible that if
the coordinator fails now after one
coordinator and one participant fails
after reaching the prepared to commit
state it's still possible for the
participants to elect a new coordinator
in which case it is possible that a
decision to abort could have been taken
by the I know by the new coordinator in
which case after coming back from know
after recovering from the failure it is
possible for the participant to move
from the prepared to commit to the abort
State now this is the participant state
diagram
we look at the actual failure scenarios
here okay now the case where the
failures can occur as usual the
participant failing in the first phase
or second phase are similar
similarly the coordinator failing in the
first phase is also similar only the
case where we need to relook at is the
second case where the coordinator
actually failed that is what we have
recorded there that means there is a
coordinator failure in the second phase
okay and then there is also one
participant failure okay or we also have
a participant failure here this is the
case where we have a problem earlier now
let us examine this case and see what
happens in this particular case in terms
of you know how the recovery takes place
in this particular case as the
coordinator fails in the second phase
along with the participant now in this
particular case there is going to be a
third phase obviously because the second
phase is not the last phase now if this
if the coordinator nobody has received
this decision from the coordinator
obviously at most the coordinator is
likely to be in the second phase which
means that the participant here could
have been in the prepared to commit
state okay prepared to commit state it
has not actually committed okay so at
most this state can be prepared to
commit it cannot be commit state the
coordinator also would have been this is
for the participant okay this is the
state of the participant okay
can be this now the state of the
coordinator can be also before commit
state now if these two are in this state
the rest of the participants can still
now elect a new coordinator and still go
ahead with the protocol because they are
still not committed they're okay they
have not committed the transaction okay
now in a simple case where the
coordinator actually passed the second
phase okay now imagine there is going to
be a sub case in this particular case
where the coordinator has passed into
the third phase that means he failed in
the third phase not in the second phase
okay now this is becomes a very simple
case coordinator fails in third phase
this is a very simple case because the
coordinator actually taken a decision to
commit and this is actually conveyed to
all the participants otherwise he would
not have gotten himself into the third
phase because unless everybody replied
for the prepared to commit state he will
not reach the third phase of actually
sending the commit message which means
even if one of the participants have
received it then only it is clear that
it has actually moved into the third
phase otherwise it is actually not moved
into the third phase so in this
particular case is easy for you to just
commit the message because you know the
decision of the coordinator that it has
been actually committed okay so this
ambiguity of not knowing the coordinator
state when it actually failed is taken
off in the case where the state of the
coordinator is known by introducing an
extra phase where the participant on the
coordinator directly do not commit but
they actually reach a before state
before commit or before prepared to
commit state before
actually committing and that is how this
ambiguity is actually resolved and that
is how the failure is handled by
introducing an extra phase for
commitment now one of the interesting
things is how is this leader election
going to happen because every time
you're actually seeing that if the
coordinator is failing it is equivalent
to actually some kind of a leader
election algorithm because you are
actually electing a leader
there is a coordinator failure they're
actually doing a leader election okay in
a simple way the leader election can be
done by assigning in terms of each
participant or each node okay NID okay
and these IDs could be in an ascending
order obviously every node is going to
get a unique ID here that means there is
a unique ID each node is going to get
and you can actually assign okay at any
given point of time a simple way assign
the highest or the new you can use the
least node ID or the highest node ID
okay so basically you can assign the
live node okay with least ID okay as the
leader however this is not simple
because now you have to actually find
out whether you are the you should take
over as leader because somebody has to
detect that the coordinator has actually
failed that means what really is going
to happen is if a participant discovers
gates go it is only going to be the
participant who is going to discover
that there is a
coordinator failure because he is
waiting for some decision of the
coordinator that is how the participant
will discover that there is a
coordinator failure so what happens is
if a participant discovers okay who it
can be anybody a participant discovers
that the coordinator has failed now what
he needs to do is he has to do an extra
okay if he basically discovers that
there was a failure of the coordinator
then he has an option of now finding out
or he has to do this process of finding
out who is the next know highest or
least node that is still life okay so he
starts now looking for the next possible
highest or least node live node and
tries to you know make that node okay as
the coordinator but then that node also
would have discovered that the
coordinator would have failed that
participant so basically all that it
needs to do is it has to see whether it
is the least node live node and if it is
so basically it now elects himself as
the coordinator and starts running the
recovery protocol okay
so in this particular way any number of
coordinator failures are tolerated by
this protocol because all that a
protocol has to do in this particular
case is make a participant whenever it
discovers that there is a coordinator
failure figure out the next highest or
least node that is supposed to take over
and if it is its turn to take over it
will basically become the coordinator
and right tries to run the protocol okay
now there are two ways this can be
further achieved in terms of how this
protocol can be run by the coordinators
one of the things properties that we
need to ensure for this protocol is
every entrance e of the protocol that
means the protocol can be run any number
of times that means a coordinator fails
then a new coordinator takes over now
while running the algorithm protocol
that coordinator could also fail which
means that now another coordinator has
to be elected and he has to take over
and this should become reentrant that
means any number of such phase
your should be possible when you are
actually recovering from the failures in
which case basically the protocol is
called reentrant protocol that means it
is tolerant to multiple failures of the
coordinator any number of times okay so
it becomes a reentrant protocol now
there are two ways this reentrant
protocol can be configured one is
a proactive way of actually making it
move forward the other is basically you
know a pessimistic way of the entrance
II okay in a simple way what the
coordinator can take as a decision is if
the coordinator is in a state of before
commit state okay
he'll basically whatever state is in he
basically enforces that more or less on
the other people okay let us understand
this point a little carefully the
coordinator has failed in the first
phase which means that no decision has
been taken by the coordinator now a new
coordinator is in place how this new
coordinator should start the protocol
okay
now new coordinator realizes that
obviously the new coordinator is not
likely to be in any other state other
than the first phase because he has not
received any message from the
coordinator so he is going to run the
entire protocol starting from the first
phase now he actually initiates the
prepare message to other participants
this is a ready message then gets into
the second phase then goes into the
third phase and things like that
okay now the way the new coordinator can
further improve the protocol is whatever
state is in okay he can actually find
out if there is any other participant
who is in a before commit state which
actually means that now we can actually
need not restart the protocol but then
he can Eno's that actually the decision
of the earlier coordinator is actually
to commit the message now you could
actually when there is a before commit
state it is possible for the protocol to
terminate as an abort because the new
coordinator now ignores this DES
but then just conducts the you know
sends a message to all the participants
now some of them are not going to reply
back to him then you can actually end up
with a board decision that is quite
possible for the new coordinator to find
out if one of the participants has
reached a before commit state in which
case actually you can force the protocol
to a commit state okay to just explain
this a little more probably nur using
our diagram you can see here the
coordinator actually the new coordinator
was elected now if he basically didn't
receive the the you know the prepared to
commit message which means that he will
be in a before state still not received
this message which could have made the
whole protocol terminate at the abort
decision okay now if you actually checks
with the other live participants and at
least one of them has actually received
this PCM state but it is not the new
coordinator it is some other node has
been elected as a coordinator now then
it can still take a commit decision
because everybody would have reached
that state so it is possible for you to
because unless all of them have replied
with a ready message this state would
not have been reached
right now the new coordinator can take a
decision to commit the transaction and
then make it a no so basically all that
that will be required for the new
elected coordinator in this case is not
only check his state but then check the
state of all live participants and based
on that restart the protocol at an
appropriate point it is done like that
the reentrant protocol terminates in a
forward direction in terms of committing
wherever there is a possibility for the
protocol to commit it will commit rather
than always ending up on the abort state
depending on the state of the new
elected
coordinator so this two two approaches
are possible in terms of recovery from
the failures as far as the coordinator
is concerned
I think what we are going to do in the
next few minutes is not only look at
this scenario of failures but then also
introduce naav the concept of what
happens with a network failure because
you are now talking about only node
failures so far we are not talking about
network failures as part of the coveri
process now in terms of network failures
as far as the protocol is concerned the
two ways of actually interpreting a
network failure a network failure
actually means that the nodes are not
reachable okay so let us take for
example a node here this node could be a
Chennai node and then this other node
could be Delhi node okay now all that
you are looking at in terms of this
system is both of them are connected by
means of some you know let us say
backbone network there could be several
links involved in connectivity between
these two nodes all that you have is
basically a network which is actually
providing this connectivity okay now
when the network actually fails in a
simple case this actually surfaces as a
time out on the other side because that
is how actually you are going to
discover okay if waiting for a reply and
this scenario actually comes as a
timeout in our diagrams as we saw there
and the timeout could be a possibility
because the network has actually failed
not the node has failed okay in either
case you won't be able to detect the
difference between a network failure and
a node failure because the node as far
as for example this Chennai node is
concerned it does not receive the reply
in time from the Delhi node it could be
a network failure it need not be a node
failure the node could be still live and
could be kicking could be doing some
work there
but when it actually sends a message let
us say a ready message the Chennai no
didn't receive the ready message this is
equivalent to actually a node failure
that means
network failure in some sense actually
translates to a node failure in a simple
case this translates to a node failure
okay but then it is probably not
appropriate to just consider a network
failure as just a node failure in our
case it still works because when the
timeout actually has reached on the
other side all that you are assuming now
is the decision of the node is to abort
okay so nothing no harm is done in this
particular case but then what could have
been a positive thing still ends up in
the negative side because you could have
still committed the message because the
node is still responded with a ready
message but since it did not reach the
the other node and it decided that when
it did not have any information the best
thing that it can do is to abort the
message or abort the transaction that is
what actually it assumes and then aborts
so basically a network failure and a
node failure in a normal case both
appear to be you know can be treated in
the same way right and that is how this
protocols both two-phase commit and
three-phase commit are resilient to
network failures in terms of translating
them to the participant field failures
okay but one has to be careful when the
network actually fails but then that
failure is not just to one failure of
one node but it can result in not able
to reach multiple nodes okay so
typically this scenario is a very simple
case where it has been translated into a
timeout case but then assume that a
network failure actually results in
multiple nodes not being reachable okay
now let us imagine we have a node in
Chennai okay let us say this is
Chennai note and then we have actually a
Bangalore node okay and then we also
have Mumbai node here okay and then we
have one of Delhi okay now it is
possible that a network that is actually
connecting them let us assume that there
is a complicated network here which
actually connects the all the nodes with
one another but then if there is
actually some kind of no hub that
connects the southern nodes together and
the northern nodes together it is quite
possible that this hub actually failed
which means that these nodes are still
can reach each other in this direction
and these nodes can still reach each
other in this direction okay now we
assume that China is the coordinator now
as far as China is concerned the whole
problem translates into the failure of
both Mumbai and Delhi because it still
is reachable Bangalore is still
reachable and let us say it replied with
whatever required messages so this
basically results in partitioning of the
whole set of nodes now we have actually
two partitions there is one partition
one here which consisting of Mumbai and
Delhi and there is another partition -
consisting of Chennai and Bangalore now
its if you carefully look at this
scenario and try to understand what
could happen in this particular scenario
it is possible that Chennai and
Bangalore could start detecting that
there is participant failures which
means that two participants have failed
and two-phase commit is resilient to
participant failure so what they
basically do is depending on which phase
you are in you might end up actually
making a decision about the transaction
okay so this basically this
you might try to run the two-phase
commit protocol saying that there are
two participant failures now as far as
Mumbai and Delhi are concerned okay for
them it translates to one coordinator
failure and one participant failure they
also try recovering back from this
problem by saying that now they will
have a new coordinator depending on what
no phase they are in and how they should
be handling this problem they might
actually try recovering back from this
failure okay now in this case it is
possible that the decisions of the two
partitions need not be consistent and
this is happening mainly because the
network the nodes are not realizing it
is a network failure they are seeing
them as failures of the participating
nodes the participating nodes are still
life and they are they are working so
for each one of them the scenario is
different unless this is discovered that
it is a network failure not a node
failure you won't be able to actually
make a distinction between a network
failure and a node failure and this
really results in a very complicated
situation where even if you use a three
phase commit protocol where the network
actually partitions the nodes into
multiple partitions you won't be able to
recover back from the problem in other
words what you are making an assumption
here is there is no partitioning that is
happening if this is the case no
partitioning of the nodes and this is an
assumption with which you are actually
working on the two-phase commit protocol
if the network partitions you have the
problem of recovering back from the
failures because all the cases which we
discussed and which we looked at are
actually taking them as participant
failures
and they're not really participant
failures and it is a network of failures
you basically will have a difficulty an
interesting assignment could be what are
those cases where the network
partitioning network partitioning can
lead to problems which is the case in
which the protocol the states of the
coordinator and the participants in
which case the partitioning could really
create a problem the other thing is to
discover if you are the majority
partition probably if you are the
majority partition probably you can
still go out and do something which
means that you have to first discover
that the system is actually partitioned
and whether you are the majority
partition and based on that you probably
can recover out of the failures it's
still a very open-ended problem in terms
of how a one can recover from network
partitions it is also interesting to see
how one can make a distinction between
network partitions and node failures for
example one way is to actually if you
just do a ping know you only know
whether the node is live or not okay so
that still remains a very interesting
problem in terms of seeing how one can
make a distinction between a node
failure and a network failure in a
distributed system right now what we
have seen is the basic commit protocols
in the next class what we are going to
see is how this commit protocols can be
integrated with concurrency protocols
for example how the two phase locking
can be integrated with two-phase commit
protocol that we are going to continue
with the next class
[Music]
you
[Music]
you
[Music]