Let's understand how Quicksilver bundles IPC with
recovery management. The secret sauce for recovery
management is the notion of transaction. It's
a light weight version of transaction. Not
the heavyweight version that you normally associate
with databases. In that sense, the notion
of a transaction in Quicksilver is very similar to what we saw in LRVM. In
fact, it is perhaps fair to say that
LRVM inherits the semantics of transactions similar to
what was proposed in the Quicksilver, because Quicksilver
predates LRVM. And the IPC calls a tag with
transaction ID. Let's say a client makes a call to a server, an IPC call to
a server. Now, because of location transparency, the
client and the servers can be on different machines
in the entire local area network. Under
the cover, the client contacts the Quicksilver kernel
on the node that it is on, let's say node A, which in turn contacts the
communication manager that's part of the operating system
of Quicksilver and implemented as a server process
above the kernel. Now, this communication manager on
node A contacts the communication manager on node
B via the kernel on node B. So all of this is happening under the covers
when a client makes an IPC call to
the server. Depending on the nature of the client-server
relationship there's going to be state associated with
this client-server interaction. Further the communication manager may
itself have state when it is communicating with
its peer on a different node of the network.
We would like to make sure that the
state that is associated with the communication manager as
well as the state associated with the high
level client-server relationship that I am showing you, all
of these are recoverable from failures. And the
failures may be things like link failure or crashing
of the server. Any of these will result
in state being left behind and what we would
like to make sure is that all such state that is left behind in the
entire distributed system is recoverable. So under the cover the communication
manager on node A contacts its transaction
manager, and the transaction manager on node A in turn contacts
its peer on node B. And now a transaction link is established
as a way of recording the trail of client-server interactions to later
facilitate picking up the breadcrumbs that
may potentially be left behind when the
client-server interaction terminates either successfully, or
unsuccessfully. So, the creator of the transaction
is the default owner of the transaction, that is the root of the
transaction T. Others are participants. In this example
I'm just showing you that a client-server relationship
exists here. The transaction manager contacts its peer,
and this guy says yes I'm willing to participate
in this transaction. So this is the transactional
tree that gets established as a by-product of
the original client-server interaction. So the owner, that
is the root of the transaction, is the coordinator
for the transaction tree that gets established.
And as we will see shortly this transaction
tree can span several sites, because a transaction
that starts here, goes to the server, may
go to other servers. So, the creator of
the transaction is the owner of the transaction.
But the owner can also change ownership as
well as change the coordinator for this transaction,
and we'll see how that is useful in a minute. The client-servers can choose to
remain completely unaware of transactions if they
so choose. In other words, the mechanisms are
there provided by the Quicksilver Operating System,
but it is up to each service provider
whether or not to use them. And there is no extra overhead for the communication
that I am showing you between these
transaction managers on these different nodes, because it
happens naturally as part of the IPC that
has to happen anyway in the distributed system.
That is the communication that is needed
for these transaction managers to handshake, to say
that yes, I've received your transaction request, I
want to participate in it, that is piggybacked
on the normal communication that happens to
support this interprocess communication between the client
and the server, through the communication managers
on these different nodes. They are piggybacked
on top of regular IPC. So there is no extra overhead for the communication
among the transaction managers. So a chain
of client-server interactions leads to a transaction tree
as client-server interactions can span multiple nodes, or
multiple sites, on the local area network. So
there is the the root of the transaction
tree, who is the owner that initiated the
original transaction through the IPC call, and these
are all the participants who said that yes,
we are also part of this IPC chain,
and we will participate in this transaction that was
initiated by this owner. Examples of how
these client-server interactions lead to the creation of
transaction trees. You can have a client
making a call to a window manager, asking
for something to be painted on the screen. And that under the covers will result
in a transaction link between these two nodes. Or a client could make a request
to a file server for opening a file.
That would result in a transaction tree getting established
between the participating nodes. And you can see
in these examples what kind of breadcrumbs will get
created on behalf of the client. The window
manager may have opened up a window on the
display and that's a piece of breadcrumb that had
been created on behalf of this client. And similarly,
the file server may have opened a file
and kept some pointers to where this client
is in that particular file. That's part of
the breadcrumb that the file server is creating
on behalf of this client. And those are the states that we would like them to
be recoverable if in fact there is any
failure. I mentioned earlier that IPC calls are tagged
with the transaction ID that gets created under the
covers. And these transaction IDs are automatic. The clients and
the servers don't have to do anything special for
that. But at the same time, they don't have to
care about them either, if they don't want to
use it in any fashion or form. The key point
is the transactions are provided in the operating system
from the point of view of recovery. And because a
client-server relationship can traverse multiple nodes or
sites in the local area network, it
is important to make sure that recoverability
has to worry about multi-site atomicity. A
transaction that originated in one node may
traverse several different nodes and leave breadcrumbs
all over the place. All those have
to be cleared up when a transaction terminates.
So there is coordination that needs to be done, and this is
where the transaction tree is very useful. And since the transaction that is
used as a secret sauce in Quicksilver is purely for recovery management,
semantics are very simple and there
is no worry about concurrency control either.