The Distributed Database System

 

How the Distributed Database System Works:

The distributed database application works as follows:

As was previously mentioned, during the running of the application, there are actually three programs running: a NameServer, a database Client (DBClient), and a Database Server (DBServer). Before either the DBServer or the DBClient start up, the NameServer must be running. With the NameServer running, the DBServer starts running and binds its NameServer client proxy class to the NameServer. The DBServer initially communicates with the NameServer by reading the ComHandle of the NameServer out of a text file on the DBServer machine (provided by the NameServer). The binding of the NameServerCP creates a NameContextCP (client proxy) object on the DBServer for the NameServer's root name context of the NameServer. Then, the DBServer also binds its NameContextCP class to the NameContext class on the NameServer. This returns a Comhandle to the DBServer, so that the DBServer can use the NameContextCP class for any future class-based RPC methods with the NameContext class.

Under the root name context of the NameServer, the DBServer creates a new NameContext object for its machine, using a name unique to all other remote machines using the name server. This could be the DNS or IP address of the DBServer, (eg. pender.ugrad.cs.ubc.ca), but this is left up to the user when starting the program. Under the newly created NameContext object, the DBServer registers all of its remotely accessible classes with the ComHandle of the DBServer on the NameServer. This is done so that the classes may be used with class-based RPC later. For the case of the DB application, the DBServer also creates an instance of a database object, and then registers it with the NameServer, under the NameContext object for the DBServer. When a new database object is created, a ServerProxy object is also created, (DatabaseSP), along with a capability for that object. The capability is then passed to the NameServer when registering the object.

When the database client application (DBClient) starts up, it binds a ClientProxy for the name server (NameServerCP) to the ComHandle of the NameServer by reading the ComHandle out of a text file on the client side provided by the name server. As with the DBServer, the binding of the NameServerCP creates a NameContextCP object on the DBClient for the rootNameContext of the NameServer. The DBClient also binds its version of the NameContextCP class to the NameServer in the same way that the DBServer did.

To access the database object created by the DBServer, the DBClient contacts the NameServer, and does a lookup under the root name context for the NameContext object of the DBServer. After the NameServer responds with a capability for the NmeContext of the DBServer, the DBClient creates a new NameContextCP object for this NameContext. Using the NameContextCP object, the DBClient performs a lookup on the NameServer for the database object previously registered by the DBServer by using the name of the database object. When the lookup is successful, the NameServer replies to the DBClient with a capability for the database object. The DBClient then creates a new database client proxy object (databaseCP) to interact with the DBServer.

Using the new databaseCP object, the DBClient can interact directly with the DBServer to perform database functions like adding tables, creating new cells, etc. When the DBClient wants to perform a function like adding a new cell to the DBServer, this can be done in one of two ways: 1)create a new cell on the DBServer and put that into an existing table, or 2) create a new cell on the DBClient, and then add this to the DBServer by passing a capability to the DBServer for this new cell. In case 2, when a new cell object is created on the DBClient side, the DBClient creates a new ServerProxy object (CellSP) for the cell, and then registers this object on the NameServer under the NameContext of the DBClient. After registering with the NameServer, the DBClient passes a capability for the cell to the DBServer. When the DBServer receives the capability, it looks up in it's ServerCap registry for it. If it is not found in the ServerCap registry, it will lookup its ClientCap registry for the capability. If it is not found there, it will create a new ClientProxy object (CellCP) for the capability, and add the CellCP to the Database.

 

 

[PhilipHenderson.com Home][Portfolio index][Distributed Database Main Page]