When the client server relationship that resulted in this formation of a
transaction tree, completes it's action, for example, let's
say that, the transaction tree got created as a result of a
client opening a file, doing a bunch of reads of the file, writes of the file,
and finally closes the file. At that point,
that interaction between the client and the server
is complete. That's when the transaction tree, that
has been created as a shadow of the
original client's relationship, would get into gear and
say, okay, now it is time to clean
up any resources that may have been partially
created. In order to satisfy that original client-server
relationship. And it is the coordinator that initiates
the termination of a transaction and the termination
initiated by the coordinator can be for commit,
or it can be an abort. And the different
color-coded arrows show you what are all the
kinds of commands that the coordinator may issue to
its subordinates. Who in turn will issue the
same commands to their subordinates. If the transaction manager,
the coordinator, decides that it is time to
commit, it might ask for vote request on committee.
Or it might ask for an abort request. Or it might send an end of commit
or abort. These are all the communications that
would be initiated by the coordinator of the transaction.
And correspondingly, responses will come back up the
tree commensurate with the request that was given.
So using again the file service as an
example, if a client that started a file service
request crashed for some reason, then the
transaction manager that is a coordinator for
their client server relationship will then send
an abort request to all the participating transaction
managers that got touched by that particular client, as a result of that file
service request. For instance it could a
directory manager, it could be data servers that
are hosting those files and so on. All
those transaction managers will get contacted by the coordinator
through this transaction tree with a request to
abort that particular transaction ID. And when they get
that request, these transaction managers can do local
cleanup, whatever that might mean. And indicate to the
transaction manager by response that yes, we have
done what it needs to be done, to clean
up the interaction that was started by that
failed IPC chain. All the different kinds of
communication that I've indicated here are opportunities to
tailor the commit protocols, depending on the criticality
of the states. That is, the nature of the bread crumbs that are going to be
left behind in the different servers. So, for
instance, if the transaction tree is representing a client-server
relationship between a client that opened a
window using the window manager on the screen.
Then if the client crashes, then the transaction
manager who was the coordinator for that particular
client will indicate to the transaction manager at
the window manager's site that this particular transaction
ID is aborting. And in that case, the
window manager can simply clean up the state,
because the state that it has got is a
volatile state. Namely, a window that it created on behalf
of the client, so it can take care of it
internally. It need not be persisted. On the other hand,
if the interaction that we're talking about involves persistent data
structure, for instance through a file server, then the file
server may have to take more complicated action. So that
is what this transaction tree allows you to do depending
on the nature of the client server relationship.
You can choose to use different commit protocols,
depending on the criticality of the states that
are associated and the nature of the breadcrumbs
that may be left behind in the different
sites, because of the client-server relationships. Persistent servers
such as a file system may need a
sophisticated commit processing, such as a two-phase commit protocol
while window manager will only need a simple one
phase commit protocol. So all of those are possible
with the structure of the transaction tree and the
kinds of requests that flow through the transaction tree both
down the tree and up the tree in response.
And this is the heavy lifting that is done
by the operating system in order to support different
classes of services that might exist in the operating system,
which may require different recovery management.