Next Previous Contents

6. Components

6.1 The Transaction Manager

6.2 The Lock Manager

The Lockmanager (LM) was intended to be as simple as possible. So a set of requi rements was formulated in order for the LM to successfully live up to the requir ements in the original assignment. These are:

Later in the development process these additional points were added when the flo w between the Transaction Manager (TM) and the LM, and the responsebility was di vided between the two components:

The LM is loosely based on the Centralized 2 phase LM described in: 'Distributed Database Systems 2nd. Ed.' by Özsu and Valduriez.

A discussion about the differences between the actual implementation and the alg oritm in DDS will come in the Implementation chapter.

The LM should be capable of communicating via the Internet using sockets. So a s erver like .

The first draft versions of the LM was programmed in C, but the author changed to Perl due to his limitiations in C. It was then the intent to write a prototype in Pe rl to translate this to C at a later point. So the current version of the LM is a Perl program.

Since the two major components was written by two different persons, a test clie nt was written in Perl to take the place of the other component during developme nt.

What the future looks like for the LM are difficult to say, but a few aspects co uld be covered or improved.

6.3 The Internal Protocol

The communication between the local TM and the centralized LM is done via a set of commands. The commands are divided into two major groups: transaction related commands and administration/development commands. The commands have the following common format:

<command>:<id>:<data>:<client>

So the commands sent from the TM to the LM has the format, if all fields are needed, but since some commands require less data the commands can be shortened:

<command>:<id>:<data>

Command:

The command is one of the ones described below.

Id:

The id field isn't mandatory, but a few commands require these to identify themselves towards the LM. The id is an Integer.

Data:

The datafield isn't mandatory either, but is utilized by those commands which need to transport further information from the the TM to the LM.

Client:

This field contains the hostname of the site issuing the command, and is concatenated by the LM itself upon succesfull communication.

So the commands sent from the TM to the LM has the format:

<command>:<id>:<data>

Transaction Related Commands

TBEG - Transaction begin

Indicates a transaction in being processed in the TM. The LM responds with a transaktion id to this request. The id is at the same time inserted in a tid list.

TEND:tid - Transaction end

Indicates a transaction is done at the TM. The id is removed from the tid list. A done is sent as response.

RDRQ:tid:table - Read request

A read lock request from the TM. First the LM checks whether it knows the table indicated in the data field. If this is the case the table is inserted into the id list associated with the id. If a write lock isn't set then it's sent to the operations queue else a lock is written in the lock list. A hostname is returned to the TM so it can find the table.

WRRQ:tid:table - Write request

A write lock request from the TM. Again the LM checks whether is knows the table indicated in the data field. If the request gets a grant it then blocks the particular table from further access. A hostname is returned to the TM.

Administration and Development Commands

These commands need the -d (debugging) flag to be set for the LM, if the issuer want to be able to see the output.

SSTL - Show sites, tables list

A command which returns a list of all sites and tables in a long comma separated line. This command was requested by the developer of the TM.

ATAB:table:sitename - Add table

A command to tell the LM about the existence of a particular table. If a table no longer should be accessible in can be removed again by the RTAB command below.

RTAB:table:sitename - Remove table

A command to remove a table from the list keeping track of known sites and tables. If a table is made accessible again the ATAB command (above) should be issued again.

RSIT:sitename - Remove site

A command to remove a whole site instead of just a table, this of course result in all sites added for a particular site are removed. And if a all sites have to be added again if they are to be accessible again.


Next Previous Contents