So, when T tries to commit,
we need to make sure that all the servers commit their updates.
In this case, T will actually commit, the transaction T will commit.
Or that none of these servers commit to their updates to their objects.
In this case, T will abort.
Okay. So this is an example of an all or
nothing property here, which we want to guarantee for the transaction.
But we also want to guarantee on the server side in a group of servers
with distributed objects.
This problem, obviously, should be familiar to you.
This is, in fact, nothing but the consensus problem.
In fact, in the concept of transactions,
it's known as the atomic commit problem here.
So, one way to do the atomic commit is known as one-phase commit.
This is a first-cut naive approach where you have a coordinator server,
say, a special server elected using lead election protocol.
You are election protocol.
The coordinator server is a special server that issues on the commit and
simply tell the 13 servers involved here, hey,
why don't you commit your object updates from transaction T?
If something goes wrong on the transaction side, if the transaction T wants to abort,
then it tells that coordinator server to abort.
And it then, the coordinator server, then relays to the servers that
they should abort their updates from transaction T to their objects.
So what's a problem with this?
Well, the first issue is that the server, the server storing the objects,
the servers one through 13, have no say in whether the transaction commits or aborts.
These servers are, after all, machines.
So, they have the memory, and the memory might be corrupted.
For instance, the object that they're storing, or
the updates from that particular transaction may be corrupted.
And in this case, you'll end up with an inconsistent system because,
as far as the transaction T and the coordinator are concerned,
they have wanted to commit but the server just cannot commit.
It just cannot commit because it does not have all the necessary information there.
Also, the server might crash before receiving the message that asks it commit.
And in this case,
the updates it had from transaction T might have been stored in memory and lost.
And in this case, you, again, have a system where you have data being lost.