Diplomarbeit

Diplomarbeit 

Graphische Oberfläche zum Offline-Studium 

des MELODY-File-Assigners 

Frank Thorsten Breuer 

Diplomarbeit 

am Fachbereich Informatik 

der Universität Dortmund 

Freitag, 

13. Oktober 2000 

Gutachter: 

Prof. Dr. Horst F. Wedde 

Prof. Dr. Heiko Krumm

Acknowledgments 

I would like to thank Prof. Dr. Horst F. Wedde for his suggestions, support and motivation. 

To Wolfgang Freund G., a postgraduate and friend, for his effort, help and our discussions. 

Thanks to Sabine Böhm for testing. 

iii

Contents 

1 Introduction 1 

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Goals of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.3 Outline of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2 Melody 3 

2.1 Task Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.1.1 Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.1.2 Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.1.3 Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.2 File Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2.1 Public Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2.2 Private Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.3 File Assigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.3.1 Get Public Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.3.2 Remove Local Public Copy . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.3.3 Remove Remote Public Copy . . . . . . . . . . . . . . . . . . . . . . . 8 

2.3.4 Emergency Remove Public Copy . . . . . . . . . . . . . . . . . . . . . 9 

2.3.5 Get Private Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.3.6 Emergency Get Private Copy . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.3.7 Remove Private Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

3 Database 11 

3.1 Goals and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

3.2 Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

3.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.3.1 Users Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.3.2 Nodes Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.3.3 Experiments Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.3.4 Nodes In Experiment Table . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.3.5 Experiment Params Table . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.3.6 Files Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.3.7 Tasks Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.3.8 Events Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.3.9 Logs Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

3.4 Logfile filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

vi CONTENTS 

4 Implementation 29 

4.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

4.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

4.3 Experiment Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

4.4 Info Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.5 Experiment Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.5.1 Experiment Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.5.2 Timer Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

5 User Manual 37 

5.1 Program Start and Connection to the Database . . . . . . . . . . . . . . . . . . . 37 

5.2 The Experiment Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.3 The Experiment Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

5.3.1 File Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

5.3.2 File Assigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

5.3.3 Changes in File Distribution . . . . . . . . . . . . . . . . . . . . . . . . 42 

5.3.4 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.4 The Experiment Info Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

6 Evaluation 47 

6.1 Database Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

6.2 Graphical User Interface Implementation . . . . . . . . . . . . . . . . . . . . . 47 

6.2.1 ExpSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

6.2.2 InfoFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

6.2.3 ExpFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

6.3 Real Logfile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

7 Conclusions and Future Outlook 49 

Used Software 51 

Bibliography 53 

A Database 55 

A.1 Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

A.2 Events table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

B Source Code and Installation 69 

C Sample Pictures 71

List of Figures 

2.1 MELODY Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.2 Degrees of Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.3 Degrees of Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.4 Task Execution Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.5 Get Public Copy Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.6 Remove Local Public Copy Protocol . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.7 Remove Remote Public Copy Protocol . . . . . . . . . . . . . . . . . . . . . . . 9 

2.8 Emergency Remove Public Copy Protocol . . . . . . . . . . . . . . . . . . . . . 10 

3.1 Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

4.1 All Classes Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

4.2 Important Classes in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

5.1 Connecting to the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.2 Experiment Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.3 Experiment Selector Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.4 Experiment Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

5.5 Experiment Window Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

5.6 Qualities of File Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

5.7 File Assigner Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

5.8 File Assigner Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

5.9 File Assigner Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.10 File Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.11 Task Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

5.12 Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

5.13 Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

5.14 Experiment Info Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

Conventions used in This Thesis 

The Typewriter Font is used for SQL tables, Java classes, and methods. The Typewriter 

Slanted Font is used for SQL columns and Java variables. 

When logfiles are quoted the Typewriter Font is used for original logfile entries. In case 

digits in the logfiles have been replaced by variables for clarity for these variables the Typewriter 

Slanted Font is used. 

References like [SG94] are used for literature, whereas references like [5] specify used software.

Chapter 1 

Introduction 

Safety-critical systems (e. g. air-plane and spacecraft automatic piloting and nuclear power plants) 

are systems where tasks do not only have to meet their deadlines, but become even critical in the 

sense that the whole system would crash after a certain number of subsequent deadline failures. 

In real-time systems the time a task needs is as important as the correctness of the result. 

MELODY is a prototype of an adaptive distributed real-time operating system that takes the 

requirements of safety-critical systems into account. The MELODY project was started at the 

Wayne State University in Detroit, Michigan and is continued at the University of Dortmund, 

Germany. 

Considering the complexity of such a system, the need for a new design methodology becomes 

evident. The MELODY system was developed by using a progress called incremental 

experimentation [WL97, sec. 2]: Refinements to MELODY base on results from the prior phase. 

The changes can be validated by experimenting with the newly added parameters. 

In MELODY two types of data files are distributed over different nodes: public copies are kept 

mutually consistent, and private copies are refreshed after updated to public copies. Reading 

tasks can access local available private copies as well as public copies. Writing tasks have got 

to work on public copies. The file assigner alters the file distribution to optimize the tasks’ file 

access [Sta96]. 

Tasks work on the files by performing simple read and write operations in a transaction-like 

phase called critical section [SG94], [Win81]. A task can only enter its critical section after 

receiving locks from all accessed files. 

MELODY is described more detailed in chapter 2. The following explains intention and aim 

of this thesis. 

1.1 Motivation 

Recent years’ air plane crashes, spacecraft losses and accidents in atomic power plants prove 

the need for research in safety-critical distributed real-time systems. Still, as far as I know, in 

this field no work has been done that is comparable to MELODY. This makes MELODY an as 

interesting as complex project. 

Way MELODY disclosures its operations is obviously a result of this complexity: every task 

and every file on every node writes at least one logfile. These logfiles are indeed in a humanreadable 

but not in a human-analysable form. Gaining an overview of what happened during an 

experiment is quite an effort and time-consuming. On the other hand the information necessary 

to analyze a special detail is spread over a large number of logfiles. Analyzing an operation on 

one node requires a lookup in a number of logfiles on many nodes to find the cohering events

2 INTRODUCTION 

necessary to comprehend the operation. The concurrency of processes on one as well as on 

different nodes aggravate this problem. 

A real-time production of the events is pointless because MELODY experiments usually last 

between a couple of seconds and a few minutes. In a fraction of a second a huge number of 

events occurs. Neither the speed of a graphical user interface nor the user’s perspective faculty 

suffice this demand. 

So there is a need for a tool that shows the information of interest in an easily understandable 

way without loosing the relevant details. The graphical user interface must depict the events 

clearly. It has got to detect related events and display them suitably. The interdependence of 

operations should become cognizable. This thesis makes a start with the MELODY file assigners 

and the tasks file access. 

1.2 Goals of this Thesis 

The goals of this thesis are: 

1. design and implementation of a graphical user interface for offline studying the MELODY 

file assigner, 

2. design and creation of a database system that keeps the required data ready for display. 

Phenomenons — in the following all denominated as ‘events’ — in particular 

the local file assigner client’s decisions to attempt a change in file distribution, 

the order of events in the file assigner lock handling, 

changes in file distribution, 

the successful and failing file access of task instances 

phases in the tasks’ life cycles 

are to be stored in the database system and to be displayed by the graphical user interface. 

1.3 Outline of this Thesis 

Chapter 2 introduces the MELODY system concepts as far as it is needed for understanding the 

graphical user interface. 

The practical work splits into two parts: the database and the graphical user interface. The 

database, its design and creation is described in Chapter 3. The graphical user interface, its 

design and implementation is treated of in Chapter 4. 

Chapter 5 appearing as a manual describing the program out of a user’s point of view. Screen 

shots illustrate the manner of representation. 

The testing and gradual use on real experiment data is described in Chapter 6. Conclusions 

and a future outlook are given in Chapter 7.

Chapter 2 

Melody 

As mentioned in chapter 1 MELODY is a safety-critical distributed real-time operating system. 

For this purpose MELODY currently provides four services briefly described in the following. 

The file assigner is explained more detailed in section 2.3. In sections 2.1 and 2.2 the MELODY 

task model resp. the file model are explained as far as required to understand the graphical user 

interface. A more profound description is found in [Lin99]. 

¢ 

¡ 

...... 

. .............. ..... ..... . Task Scheduler ....... File Assigner .......................................................... 

¥¨ 

£ 

£ 

¥ 

¥ ¥ 

¥ ¥ ¥ ¥ ¥ ¥§¦ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ 

¤ 

¤ 

¢ 

........... 

¡ 

.... 

. ....... ......... 

............... Run Time Monitor .. File Server ............................................................. 

Figure 2.1: MELODY Servers 

Task Scheduler The Task Scheduler schedules the arrived tasks considering the task’s estimated 

execution time (derived from the file server’s history), its deadline, list of required files and 

static priority. The task scheduler distinguishes between strongly schedulable instances, 

which are scheduled, weakly schedulable instances, which are aborted but would have 

been scheduled, if the file distribution would have been appropiate, and non-schedulable 

tasks, which are aborted, too. 

Essentially critical tasks are not scheduled, but passed to the run-time monitor directly. 

Run Time Monitor Since the scheduler is invoced prior to resource allocation, it is left without 

exact information about the tasks’ execution time. Hence the run-time monitor is needed 

to abort tasks that are going to miss their deadlines after being scheduled. 

The run-time monitor consists of three sub-servers: the file monitor, the task monitor, and 

the integration controler. The task monitor aborts tasks, which are expected to miss their 

deadline, by monitoring the tasks’ life cycle (see figure 2.4). The file monitor checks, if 

file operations queued by the file server origin from a task instance that has already missed 

its deadline and removes these requests. The integration controler invokes the file server 

and task scheduler in a ratio that prevents too many tasks being scheduled and competing 

for the shared files. 

File Server The file server selects task instances, which have been scheduled, and tries to allocate 

the needed files. This is done utilizing the delayed insertion protocol [Dan92]. It

4 MELODY 

performes the read and write operations. The file server maintains a history about the read 

and write access for every file, requested by a task. This history is used to calculate a task’s 

estimated execution time regarded by the task scheduler. 

Having heard about public copy updates, the file server requests updates of his respective 

private copies. 

File Assigner The file assigner changes the file distribution in terms of location, number, and 

quality, in order to answer the tasks’ needs. Section 2.3 deals with the file assigner. 

2.1 Task Model 

Tasks perform simple read and write operations on files. Tasks are executed on a regular basis. 

Every instance of a task has got to go through a life cycle of four phases. In safety-critical 

systems tasks are assigned a criticality and sensitivity repesenting the task’s importance for the 

system. 

2.1.1 Criticality 

The criticality of a task is a gauge for the importance of the task to the entire system. In an 

aviation example the autopiloting is a critical task becoming even more critical, when landing, 

while the hot water preparation in the on-board kitchen is non-critical. Formally the criticality 

 

is defined as a © cirticality value assigned to a © © task. If , the task is called non critical, if 

© © , critical, and if ©© , essentially critical. 

© 

essentially critical critical non critical 

£ 

£ 

¡ 

highest criticality lowest criticality 

© 

© 

Figure 2.2: Degrees of Criticality 

The © relative criticality of a task instance is set to the task’s © criticality value , if the 

 

task is (© © either non-critical ) or (©© essentially crititical ) or the last 

task instance 

was successful. Otherwise the relative criticality value is set to the task’s criticality value less 

the number of subsequent deadline failures making the instance more critical but not dropping 

below a © minumum of . 

2.1.2 Sensitivity 

The sensitivity of a task expresses the task’s dependence on up-to-date data. In the above example 

on normal flight level the autopiloting can cope with an inexactness of a few meters, but when 

landing especially immediately before touchdown, the exact height is needed. Formally the 

 

sensitivity is defined as a sensitivity value assigned to a task. If , the task is called 

robust, if , sensitive, and if , essentially sensitive. 

The relative sensitivity of a task instance is set to the task’s sensitivity value , if the 

 

task is ( either robust ) or ( essentially sensitive ) or the last task instance was 

successful. Otherwise the relative sensitivity value is set to the task’s sensitivity value plus the 

number of subsequent deadline failures making the instance more robust but not going over a 

maximum of .

2.1 Task Model 5 

essentially sensitive sensitive non sensitive 

£ 

£ 

¡ 

highest sensitivity lowest sensitivity 

2.1.3 Life Cycle 

 

 

 

Figure 2.3: Degrees of Sensitivity 

The four phases every successful task instance goes through are the following: 

Scheduling phase In case the task scheduler recognizes the task instance to be schedulable, 

the instance is scheduled considering its priority and deadline. Otherwise the instance is 

aborted. 

Location phase During the location phase the file server locates all file copies required by the 

task instance. Reading tasks locate either a local copy — shadow or private, depending on 

the relative criticality and sensitivity — or a remote shadow copy. Writing tasks locate all 

public file copies. 

Acquisition phase The acquisition phase is different for reading and writing tasks: 

Writing tasks go through the allocation and locking subphases. These tasks have to compete 

for mutual exclusive file access using the delayed insertion protocol [Dan92]. The 

subphases correspond to the steps in the protocol directly. In the allocation subphase the 

instance sends requests to all file copies and waits for corresponding ready messages. After 

acquiring all ready messages the instance begins its locking subphase. During this phase 

the instance sends schedule messages to the file copies and waits for the lock messages. 

Reading tasks are not required to compete for file access. Nevertheless they have to be 

queued at the node holding the copy and gain a read lock. 

Computation phase After completing its acquisition phase successfully the instance begins its 

computation phase. It sends the read and write operations to all files and waits for responses. 

A message with a successful status is returned, in case the remote file server was 

able to perform the operation before the task’s deadline. Otherwise a failed is returned. 

If any access failed, the instance failed. Nevertheless all write operations are always performed 

to ensure the consistency of all public file copies. 

£ 

Other system 

activities 

Creation time 

Scheduling 

phase 

£ 

Location 

phase 

Start time 

Aquisition 

phase 

Execution time 

Computation 

phase 

Figure 2.4: Task Execution Phases 

£ 

Laxity 

Completion 

time 

£ 

Deadline 

Release phase If the instance was aborted or failed, it begins its release phase to give back all 

gained locks. 

Whether an instance was aborted or failed, it is marked as having failed in the sense of section 

2.1.1 and 2.1.2. 

¡

6 MELODY 

2.2 File Model 

As a distributed system MELODY replicates and distributes data objects (files) over different 

nodes. MELODY provides two types of file copies: public und private. For each public copy a 

shadow copy is created. 

2.2.1 Public Copies 

Public copies are shared resources and can be accessed by all tasks on every node. They always 

contain the latest data and are kept mutually consistent by a strong concurrency protocol. Since 

all public copies have to be updated, the time exposure for write operations depends directly on 

the number of public copies. 

For each public copy a shadow copy is created to allow reading access, while the file is being 

updated. Updating the shadow copy takes place automatically successive to the update to the 

public copy. 

2.2.2 Private Copies 

Private copies are not shared with other nodes in the MELODY system. They merly utilize a 

weak concurrency protocol, refreshing the copy some time after a public copy update. A private 

copy can only be accessed by reading tasks on the same node, which additionally have to be 

robust. Private copies may reduce the time exposure for read operations without increasing the 

write overhead. 

2.3 File Assigner 

The goal of the MELODY file assigner is to improve the availability of files and to better the 

system survivability. The available means are changes to file distribution in terms of location, 

number, and quality. The file assigner trades-off the costs for various alternative file distributions 

under changing request and deadline failure patterns. Therefore it cooperates with the local file 

server and remote file assigners. In this regard costs are overhead operations for multiple file 

copies and communication delays for remote operations. 

The difficulty is that changes to support one task may hamper other tasks. The following 

alternatives illustrate this. 

Creating a private copy of a file speeds up read access to the file originating from this node, 

without affecting write access. Unfortunately private copies can only be read by robust 

tasks. 

Creating a public copy of a file accelerates all read access to the file at least for tasks on this 

node. To writing tasks the additional copy involves more overhead. 

Moving a public copy from one node to another means more cost for reading tasks on one host 

resp. less cost on the other one. 

Reducing the number of public copies allows faster write access, while reading tasks at least 

on the affected node suffer. 

Deleting a private copy influences only robust reading tasks on the affected node. 

The MELODY file assigner has been divided into a server and a client part:

2.3 File Assigner 7 

¢ 

¢ 

Denied 

Not Possible 

Creation 

Create Done 

File Assigner Client 

Get Public Copy 

 

Check FA-Lock 

Granted 

¤ 

Create or Move Copy 

 

 

 

Movement 

 

Request Creation Request Movement 

¡ 

 

 

 

 

Move Done 

File Assigner Server 

Request Get Copy 

 

 

 

 

§ 

 

FA-Lock Requested 

 

 

 

Release FA-Lock 

 

Release Done 

 

 

 

 

 

 

Respond FA Lock with 

relocation and replication info 

 

 

 

Release FA Lock 

 

 

 

 

§ 

 

FA-Lock Released 

 

 

 

 

 

Respond Release 

Figure 2.5: Get Public Copy Protocol 

File assigner client The file assigner client decides how to change the file distribution to improve 

the costs for accessing a certain file. On account of the drastic effects of changes 

in distribution of public copies the file assigner client has got to ask for the file assigner 

servers’ consent, i. e. to retrieve a lock on the file. 

File assigner server The file assigner server handles requests for information regarding file 

copies on its node, their costs and needs for copies. The file assigner lock procedure 

ensures that only one file assigner client changes the distribution of a certain file at any 

time. 

The above mentioned lock procedure is realized utilizing the priority insertion protocol 

[Dan92]. The below sections describe the possible file assigner client decisions, the conditions 

for making these decisions, and the resulting file assigner lock procedures. 

2.3.1 Get Public Copy 

This service (see figure 2.5) is executed after the local file assigner has determined that a number 

of local read access requests have failed and a public copy should be created at the local node. 

The file assigner client sends get-copy-requests to all file assigner servers holding a copy of 

the respective file. In response the file assigner servers grant or deny a file assigner lock. In 

the case a file assigner server grants a lock it includes information whether it would allow the 

relocation of its local copy, if local read access on his node would not significantly suffer, or the 

creation of an additional one, if write access from his node would not significantly suffer.

8 MELODY 

¢ 

¢ 

Denied 

Not Possible 


Remove Local Public Copy 

¡ 

 

Check FA-Lock 

Granted 

¤ 

Check Delete 

Deletion Possible 

¤ 

Delete Local Copy 

Deletion Done 

¤ 


 

Release Done 


Request Delete 

 

 

 

 

§ 

 


 

 

 

 

 

Respond FA Lock 

 

 

 


 

 

 

 

§ 

 


 

 

 

 

 


Figure 2.6: Remove Local Public Copy Protocol 

If one file assigner server has refused a lock, the file assigner client releases all already 

obtained locks and finishes the request. Having received responses from all file assigner servers 

the fac checks, if a file assigner server has allowed to move his public copy. If so, the file assigner 

client leads the file server to move this copy. If not, the file assigner client determines, if all file 

assigner server agree to create a new copy. If creation is possible, the local file server creates a 

new local copy, otherwise the file assigner client cannot do anything. Last step is the release of 

all obtained locks. 

2.3.2 Remove Local Public Copy 

Once the local file assigner client has determined that a local public copy should be removed, 

delete copy requests (see figure 2.6) are sent to all file assigner servers holding a public copy of 

this file. 

If all file assigner servers have granted a file assigner lock, the file assigner client ensures, 

that the number of public copies does not drop below the minimum number. If this condition is 

met, the local file server deletes the local copy. At the end of this service the file assigner client 

releases all obtained locks. 

2.3.3 Remove Remote Public Copy 

After determining a number of failing tasks writing on a file the file assigner client tries to 

reduce the number of public copies. Thereto is sends delete copy requests to all file assigner

2.3 File Assigner 9 

¢ 

¢ 

Denied 

Not Possible 


Remove Remote Public Copy 

¡ 

 

Check FA-Lock 

Granted 

¤ 

Check Delete 

Deletion Possible 

¤ 

Request Deletion 

Deletion Done 

¤ 


 

Release Done 


Request Delete Copy 

 

 

 

 

§ 

 


 

 

 

 

 


with deletion info 

 

 

 


 

 

 

 

§ 

 


 

 

 

 

 


Figure 2.7: Remove Remote Public Copy Protocol 

server holding a copy of this file (see figure 2.7). 

Compared to removing a local copy (section 2.3.2) this change in file distribution affects 

reading tasks on other nodes. So the file assigner servers have not only to grant a file assigner 

lock but also decide whether or not they allow a deletion of their copy. If all locks could be 

obtained and a file assigner server allows the deletion, the file assigner client requests the local 

file server to delete the copy. 

2.3.4 Emergency Remove Public Copy 

Once a nearly sessentially critical writing task has failed and endangers the survivability of the 

system (emergency situation) this service is invoced in order to reduce the number of public 

copies of the respective file. So the chance that the next (essentially critical) instance of the 

failing task will be successful. 

The file assigner client sends emergency requests to all file assigner servers holding a copy of 

this file. These, in turn, grant or deny a file assigner lock. If all file assigner servers have granted 

locks, the file assigner client selects the copy with the lowest number of read access requests 

according to the conveyed read access histories. 

The file assigner client leads the file server to delete this copy. At the end of this service just 

as of the services above the file assigner locks are released.

10 MELODY 

Denied 

Not Possible 

2.3.5 Get Private Copy 

¢ 

¢ 


Emerg. Remove Public Copy 

¡ 

 

Check FA-Lock 

Granted 

¤ 

Check Delete 

¤ 

Request Deletion 

Delete node selected 

Deletion Done 

¤ 


 

Release Done 


Request Emergency Copy 

 

 

 

 

§ 

 


 

 

 

 

 


with read access history 

 

 

 


 

 

 

 

§ 

 


 

 

 

 

 


Figure 2.8: Emergency Remove Public Copy Protocol 

The file assigner client determines the need for a local private copy, if a number of failing robust 

local read access requests have taken place. 

The change in distribution of private copies does not affect remote nodes. So the file assigner 

client can issue a request to the file server to create a private copy without a previous file assigner 

lock procedure. 

2.3.6 Emergency Get Private Copy 

When a nearly essentially critical reading task has failed, the system survivability might be compromised. 

Under all circumstances a local private copy has to be created, to ensure successful 

read access for the next (essentially critical) task instance. 

Apart from that this service is the same as get private copy (see section 2.3.5). 

2.3.7 Remove Private Copy 

If a private copy is rarely accessed, the file assigner client decides to remove it. Since this does 

not affect the remote nodes either, this is done without competing for file assigner locks.

Chapter 3 

Database 

The database system is the first part of the practical work done in writing this thesis. The database 

keeps the logfile data ready for display by the graphical user interface. 

This chapter lists requirements the database has to satisfy, gives the reasons, why POST- 

GRESQL is the chosen database system, and explains the design and creation of the MELODY 

database. 

3.1 Goals and Requirements 

The database system, as important part of the graphical user interface, provides the following 

services: 

interface between the MELODY system and the graphical user interface 

management and accumulation of MELODY experiments run by different users. 

The database system should allow 

a possibility to configurate MELODY experiments 

extentions for future versions of MELODY. 

The chosen database system should satisfy the requirements below: 

availability for the LINUX operation system 

SQL as query language 

high stability 

adequate speed with moderate resource consumption. 

3.2 Choice 

The two eligible database systems are: 

MYSQL [3] 

POSTGRESQL [4]

12 DATABASE 

Both are included in the S.U.S.E. LINUX 6.x distributions [5]. POSTGRESQL derived from 

the Berkeley Postgres Project and is distributed by the Postgres Development Team under the 

Berkeley License. MYSQL is free for non-comercial use, the TCX DataKonsult AB, Stockholm, 

Sweden charges for commercial licenses. 

MYSQL [AWCD00] implements a sufficient subset of the SQL standard. It does not support 

constraints or foreign keys. Insertions and updates are faster, selects do not show a significant 

difference compared to using POSTGRESQL. 

POSTGRESQL [Pos00] offers a wider selection of SQL features, but not as many as described 

in [Mom00], a book that turned out to be science fiction to some extend. Some complicated updates 

and inserts become instable on large amounts of data. None of these features is needed 

neiher by the graphical user interface nor by the filter described in 3.4, so this lack is no disadvantage 

in this connexion. POSTGRESQL supports transactions and check constraints. Check 

constraints, which can replace foreign keys, and transactions are an inestimable advantage to the 

databases consistency. 

Since the higher speed of MYSQL is insignificant and POSTGRESQL’s advantages prevail, 

the choice is POSTGRESQL. Nevertheless the graphical user interface uses only basic SQLstandard 

queries in order to stay database system independent. 

3.3 Structure 

The structure of the MELODY database has been modelled making use of [1]. Figure 3.1 shows 

the database modell. The generated sql statements have been optimized for POSTGRESQL manualy: 

The generated foreign keys have been replaced by sql functions and check constraints. The 

constraints for the LOGS table are entirely hand made. 

The sql statements creating the tables as well as the functions are presented in Appendix A.1 

(pp. 55). In the following the main tables are outlined. 

3.3.1 Users Table 

The database table ‘USERS’ stores all MELODY users. The table consists of the following 

columns: 

UserID SMALLINT UNIQUE PRIMARY KEY 

is a unique user id. It is referenced by the EXPERIMENTS table (s. section 3.3.3). 

Name VARCHAR(30) 

holds the user’s short name, e. g. his 1 unix account. 

Description VARCHAR(80) 

gives a description e. g. his full name. 

The sql function userOK(UserID) returns , if the passed UserID is found in the 

USERS table, otherwise. The UserID’s check constraint in the table EXPERIMENTS (s. 

section 3.3.3) calls this function to see, if the user exists. 

3.3.2 Nodes Table 

The database table ‘NODES’ holds a list of all nodes used for MELODY experiments. The table 

consists of the following columns: 

1 or her

3.3 Structure 13 

Figure 3.1: Database Structure

14 DATABASE 

NodeID SMALLINT UNIQUE PRIMARY KEY 

is a unique node id. It is referenced by the table NODES IN EXPERIMENT (s. section 

3.3.4). 

Name VARCHAR(30) 

is the node’s DNS 2 name in its short form without domain. 

Ok BOOLEAN 

indicates, if the node can currently be used for experiments. 

The sql function nodeOK(NodeID) returns , if the passed NodeID is found in the 

NODES table, otherwise. It is used by a check contraint in NODES IN EXPERIMENT (s. 

section 3.3.4) to see, if its NodeID points to an existing node. 

3.3.3 Experiments Table 

The database table ‘EXPERIMENTS’ stores a list of all MELODY experiments. The table consists 

of the following columns: 

ExpID INTEGER UNIQUE PRIMARY KEY 

is a unique id for every experiment. It is referenced by many other tables, e. g. LOGS (s. 

section 3.3.9), in order to relate each of their rows to a distinct experiment. 

UserID SMALLINT 

references a UserID in the USERS table (s. section 3.3.1). 

DateTime TIMESTAMP 

indicates when the experiment was inserted. 


gives a short description of the experiment. 

The sql function expOK(ExpID) returns , if the passed ExpID is found in this table, 

otherwise. It is called by check constraints of all tables, which need to reference an experiment. 

3.3.4 Nodes In Experiment Table 

The database table ‘NODES IN EXPERIMENT’ remembers which nodes took part in which experiment. 

The table consists of the following columns: 

ExpID INTEGER 

references an ExpID in the EXPERIMENTS table. 

NodeID SMALLINT 

references an NodeID in the NODES table. 

The UNIQUE INDEX NODES IN EXP guaranties every node is assiciated with an experiment 

only once. 

The sql function nodeInExp(ExpID, NodeID) returns , if NodeID took part in ExpID, 

otherwise. It is called by other tables’ check constraints, whenever a node taking part in 

an experiment is referenced. 

2 Domain Name System


3.3.5 Experiment Params Table 

The database table ‘EXPERIMENT PARAMS’ stores parameters for every MELODY experiment. 


ExpID INTEGER 

references an ExpID in EXPERIMENTS (s. section 3.3.3). 

Critical SMALLINT 

is the threshold that, if reached by a task’s criticality, means the task is critical. 

EssCritical SMALLINT 

is the threshold that, if exceeded by a task’s criticality, means the task is essentially critical. 

Sensitive SMALLINT 

is the threshold that, if reached by a task’s criticality, means the task is sensitive. 

EssSensitive SMALLINT 

is the threshold that, if exceeded by a task’s criticality, means the task is essentially sensitive. 

These four thresholds are explained with full details in [Lin99, sec 3.1] 

SchIntegID SMALLINT 

references a scheduler integration type listed in the SCHINTEGRATION table. At present 

‘periodic’, ‘dynamic’, ‘adjusted’ and ‘joined’ are possible. This choice is described in 

[Lin99, sec. 7.1.1] and [WL97, sec. 2.4]. 

SchParams VARCHAR(20) 

a character string containing the scheduler parameters, which depend on the scheduler 

integration type. 

RTIntegID SMALLINT 

references a scheduler integration type listed in the RTINTEGRATION table. At present 

‘abort before computation’, ‘earliest abort before acquisition’, ‘medium abort before acquisition’ 

and ‘latest abort before acquisition’ are possible. See [WLS99, sec. 4]. 

FAIntegID SMALLINT 

references a scheduler integration type listed in the FAINTEGRATION table. At present 

‘task driven’, ‘file driven’, ‘history’ and ‘disabled’ are possible. Further information on 

the file assiner integration is found in [Lin99, sec. 6.1.4] and [Sta96, sec 4.4]. 

FAThNotUsed SMALLINT 

FAThGetCopy SMALLINT 

FAThAllowCopy SMALLINT 

FAThReduceCopy SMALLINT 

FAThDeleteCopy SMALLINT 

FATryWait SMALLINT 

FAChangeWait SMALLINT 

FAHistWindow SMALLINT 

The above parameters are file assigner parameters described in [Sta96, sec. 4.2]. 

MinPublic SMALLINT 

is the guarantied minimum number of public copies of each file. This parameter biasses 

the fault-tolerance properties of MELODY.

16 DATABASE 

MaxPublic SMALLINT 

is the maximum number of public copies the file assigner must not exceed. 

FileModelID SMALLINT 

references a scheduler integration type listed in the FILEMODELS table. At present 

‘melody’, ‘public’ and ‘private’ are possible. 

ServerPrio SMALLINT 

defines the basic server priority. The actual server priorities are set relative to this one. 

SyncMaster SMALLINT 

references the node that is used as master for time synchronisation. See [Lin99, app. B] 

and [WF00]. 

3.3.6 Files Table 

The database table ‘FILES’ determines which files took part in an experiment, and on which 

node public and private copies were initially created. For each initial copy one row is inserted. 


ExpID INTEGER 


FileID INTEGER 

is the file’s id. 


references an NodeID in the NODES IN EXPERIMENTS table that takes part in the experiment. 

Shows the node where a copy is initially created. 

Type CHAR(4) 

Determines the type (‘PUB’, ‘PRIV’) of the copy in initially created. 


can hold a description of the file. 

The UNIQUE INDEX FILES IN EXP guaranties that every initial file copy on a node is 

unique within an experiment. 

The sql function fileInExp(ExpID, FileID) returns , if NodeID occures in ExpID, 

otherwise. It is called by other tables’ check constraints, whenever a file taking part in 

an experiment is referenced. 

3.3.7 Tasks Table 

The database table ‘TASKS’ stores the information needed about tasks that are run in an experiment. 

For each file a task accesses one row is inserted. The table consists of the following 

columns: 

ExpID INTEGER 


TaskID SMALLINT 

is the task’s id.



references the NodeID in the NODES IN EXPERIMENTS table where the task is run. 

Criticality SMALLINT 

determines the task’s criticality. 

Sensitivity SMALLINT 

determines the task’s sensitivity. 

FileID SMALLINT 

references a FileID in the FILES table. shows which files is accessed by the task. 

ReadWrite CHAR(1) 

indicates, if the task reads on (‘R’) or writes to (‘W’) FileID. 


can hold a description of the file. 

The sql function taskInExp(ExpID, TaskID) returns , if NodeID occures in ExpID, 

otherwise. It is called by a check constraint in the LOGS table to see, if the referenced 

task exists. 

The UNIQUE INDEX TASKS IN EXP guaranties that no multiple rows are inserted. 

3.3.8 Events Table 

The database table ‘EVENTS’ provides information about all events that are stored in the LOGS 

table (s. section 3.3.9) and displayed by the graphical user interface. The priority assignment 

is to fix which columns in the LOGS table are mandatory for the respective events. The table 

consists of the following columns: 

EventID SMALLINT UNIQUE PRIMARY KEY 

is the unique id referenced by the LOGS table. 

Abr VARCHAR(30) 

is a short name of the event. 


provides a short description of the event. 

LogFilePattern VARCHAR(80) 

The filter program (s. section 3.4) uses this pattern to find the rows in the logfiles according 

to this event. 

LogFileType VARCHAR(12) 

By stating a file extention, the LogFileType determines which logfiles the filter program 

searches for the pattern. 

LogFileMulti BOOL 

Some events are reported in several logfiles on different hosts. If this flag is set, the filter 

program ignores all events that do not affect the local node. 

FileID BOOL 

NodeID BOOL

18 DATABASE 

PeerNodeID BOOL 

TaskID BOOL 

Instance BOOL 

Criticality BOOL 

Sensitivity BOOL 

Data BOOL 

The above columns indicate, if the according columns in the LOGS table are mandatory. 

There is related function ‘...Mand(EventID)’ for each of these flags that is called by 

the LOGS table’s check constraints. 

Table 3.1 notes the inserted events down. In the following the events are described in more 

detail. All inhabitants as inserted into database are presented in Appendix A.2 on page 63. 

EventID 

Abreviation 

1100 GetPublic 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1101 RemovePublicLocal 

1102 RemovePublicRemote 

1103 RemoveEmergencyPublic 

1104 GetPrivate 

1105 GetEmergencyPrivate 

1106 RemovePrivate 

1110 LockDenied 

1111 LockGranted 

1112 LockWinnerDeny 

1113 LockWinnerMove 

1114 LockWinnerCopy 

1115 LockWinnerDelete 

1116 LockWinnerEmergencyRemovePublic 

1117 LockRelease 

1200 CreatePrivateCopy 

1201 CreatePublicCopy 

1202 ChangePrivatePublicCopy 

1203 DeletePrivateCopy 

1204 DeletePublicCopy 

1205 ActivePublicCopy 

1206 ActiveShadowCopy 

1207 ActivePrivateCopy 

1208 DeactivePublicCopy 

1209 DeactivePrivateCopy 

1300 RequestDataCopy 

1301 ReceivePublicCopy 

1302 ReceivePrivateCopy 

1303 ReceiveCopyLength 

1304 ReceiveDataPortion 

FileID 

NodeID 

Table 3.1: Displayed Events 

PeerNodeID 

TaskID 

Instance 

Criticality 

Sensitivity 

Data 

cont’d on next page


EventID 

Abreviation 

cont’d from last page 

1305 ReceiveCopyComplete 

2000 InstanceArrival 

2001 SchedulePhase 

2002 Scheduled 

2003 LocationPhase 

2004 LocatedFile 

2005 AquisitionPhase 

2006 AllocationSubPhase 

2007 ReadyFile 

2008 LockingSubPhase 

2009 LockedFile 

2019 GiveBackLock 

2010 ComputationPhase 

2011 Reading 

2018 Writing 

2012 Succeeding 

2013 Aborting 

2014 ReleasePhase 

2015 ReleaseFile 

2016 Success 

2017 Failed 

FileID 

NodeID 

Table 3.1: Displayed Events 

GetPublic The file assigner client at NodeID has decided to try to create a local public copy 

of FileID. 

This event coincides with the 

“realtimestamp | GET PUBLIC COPY” 

log file entries in the file ‘Node/FILEFileID.moving’. 

RemovePublicLocal The file assigner client at NodeID has decided to try to remove his local 

public copy of FileID. 


“realtimestamp | REMOVE PUBLIC COPY LOCAL” 


RemovePublicRemote The file assigner client at NodeID has decided to try to reduce the 

number of public copies of FileID. 


“realtimestamp | REMOVE PUBLIC COPY REMOTE” 


PeerNodeID 

TaskID 

Instance 

Criticality 

Sensitivity 

Data

20 DATABASE 

RemoveEmergencyPublic In an emergency situation the file assigner client at NodeID has 

decided to try to reduce the number of public copies of FileID. 


“realtimestamp | EMERGNCY PUBLIC COPY REMOTE” 


GetPrivate The file assigner client at NodeID has decided to create a local private copy of 

FileID. 


“realtimestamp | GET PRIVATE COPY” 


GetEmergencyPrivate In an emergency situation the file assigner client at NodeID has decided 

to create a local private copy of FileID. 


“realtimestamp | EMERGNCY PRIVATE COPY REMOTE” 


RemovePrivate The file assigner client at NodeID has decided to remove his local private 

copy of FileID. 


“realtimestamp | REMOVE PRIVATE COPY LOCAL” 


LockDenied The file assigner server at PeerNodeID has refused a file assigner lock for 

FileID requested by NodeID. 


“realtimestamp | LOCK DENIED AT PeerNode” 


LockGranted The file assigner server at PeerNodeID has granted a file assigner lock for 

FileID requested by NodeID. 


“realtimestamp | LOCK GRANTED BY PeerNode ...” 


LockWinnerDeny All file assigner servers holding a copy of FileID have granted a file 

assigner lock for FileID requested by NodeID, but refuse the requested action. If this event 

follows an ‘RemoveEmergencyPublic’ event, it means that at least one file assigner server has 

refused this file assigner lock requested by NodeID. 


“realtimestamp | REQUEST DENIED HISTORY” 


LockWinnerMove All file assigner servers holding a copy of FileID have granted a file assigner 

lock for FileID requested by NodeID, the file assigner server at PeerNodeID allows 

to move his public copy of this file.



“realtimestamp | MOVING PUBLIC FROM PeerNode” 


LockWinnerCopy All file assigner servers holding a copy of FileID have granted a file 

assigner lock for FileID requested by NodeID and allow to create a new public copy at this 

node. The copy will be received from PeerNodeID. 


“realtimestamp | GETTING PUBLIC FROM PeerNode” 


LockWinnerDelete All file assigner servers holding a copy of FileID have granted a file 

assigner lock for FileID requested by NodeID and allow to remove a public copy. The copy 

at PeerNodeID will be removed. 


“realtimestamp | REMOVING PUBLIC AT PeerNode” 


LockWinnerEmergencyRemovePublic All file assigner servers holding a copy of FileID 

have granted a file assigner lock for FileID requested by NodeID, which is in an emergency 

situation. 


“realtimestamp | "EMERGNCY PUBLIC FROM Node” 


LockRelease The file assigner client at PeerNodeID releases file assigner lock at NodeID 

for FileID. 


“realtimestamp | LOCK PUBLIC RECEIVE WRITE/ASSIGN RELEASE 

FROM PeerNode” 


Unlike the ‘Lock Granted’ and ‘Lock Denied’ events this log file entry is found in the 

PeerNodeID’s logs, so compared to the preceding events NodeID and PeerNodeID are 

swapped. 

CreatePrivateCopy NodeID starts creating a local private copy of FileID. 


“realtimestamp | CREATE PRIVATE COPY AT PeerNode” 


This event is logged on every node. In the database only one entry is necessary, so this event 

may only be inserted, if NodeID equals PeerNodeID. 

CreatePublicCopy NodeID starts creating a local public copy of FileID. 


“realtimestamp | CREATE PUBLIC COPY AT PeerNode” 



may only be inserted, if NodeID equals PeerNodeID.

22 DATABASE 

ChangePrivatePublicCopy NodeID starts changing his local private copy of FileID into a 

public one. 


“realtimestamp | CHANGING PRIVATE COPY AT PeerNode” 




DeletePrivateCopy NodeID starts deleting his local private copy of FileID. 


“realtimestamp | DELETE PRIVATE COPY AT PeerNode” 




DeletePublicCopy NodeID starts deleting his local public copy of FileID. 


“realtimestamp | DELETE PUBLIC COPY AT PeerNode” 




ActivePublicCopy A public copy of FileID has been created on NodeID. 


“realtimestamp | ACTIVE PUBLIC COPY AT PeerNode” 




ActiveShadowCopy A shadow copy of FileID has been created on NodeID. 


“realtimestamp | ACTIVE SHADOW COPY AT PeerNode” 




ActivePrivateCopy A private copy of FileID has been created on NodeID. 


“realtimestamp | ACTIVE PRIVATE COPY AT PeerNode” 




DeactivePublicCopy The public copy of FileID has been removed from NodeID. 


“realtimestamp | DEACTIVE PUBLIC COPY AT PeerNode” 

log file entries in the file ‘Node/FILEFileID.moving’.




DeactivePrivateCopy The private copy of FileID has been removed from NodeID. 


“realtimestamp | DEACTIVE PRIVATE COPY AT PeerNode” 




RequestDataCopy The file server on NodeID has asked the file server on PeerNodeID for 

a copy of FileID. 


“realtimestamp | REQUEST DATA COPY FROM PeerNode” 


ReceivePublicCopy The file server on NodeID has started to receive a public copy of FileID. 


“realtimestamp | RECEIVE COPY PUBLIC ...” 


ReceivePrivateCopy The file server on NodeID has started to receive a private copy of 

FileID. 


“realtimestamp | RECEIVE COPY PRIVATE ...” 


ReceiveCopyLength The file server on NodeID has received the length (Data) of FileID, 

he is receiving. 


“realtimestamp | RECEIVE COPY LENGTH data” 


ReceiveDataPortion The file server on NodeID has received a portion with length (Data) of 

FileID. 


“realtimestamp | RECEIVE DATA PORTION data” 


ReceiveCopyComplete The file server on NodeID has received all portion of FileID. 


“realtimestamp | RECEIVE COPY COMPLETE” 


InstanceArrival Instance of TaskID on NodeID has arrived. 


“realtimestamp | INSTANCE Instance - INSTANCE ARRIVAL

24 DATABASE 

STARTED ...” 

log file entries in the file ‘Node/TASKTaskID.access’. 

SchedulePhase Instance of TaskID on NodeID has begun its scheduling phase. It will 

be scheduled with Citicality and Sensitivity . 


“realtimestamp | INSTANCE Instance - BEGINNING SCHEDULE PHASE 

[Criticality,Sensitivity] ...” 


Scheduled Instance of TaskID on NodeID has been scheduled. 


“realtimestamp | INSTANCE Instance - SCHEDULED” 


LocationPhase Instance of TaskID on NodeID has begun its location phase. 


“realtimestamp | INSTANCE Instance - BEGINNING LOCATION PHASE” 


LocatedFile Instance of TaskID on NodeID has located FileID on PeerNodeID. 


“realtimestamp | INSTANCE Instance - LOCATED FILE 

FileID@PeerNodeID ...” 


AquisitionPhase Instance of TaskID on NodeID has begun its aquisition phase. 


“realtimestamp | INSTANCE Instance - BEGINNING AQUISITION PHASE” 


AllocationSubPhase Instance of TaskID on NodeID has begun its allocation subphase. 

This events occurs only, if the task reads at least one file. 


“realtimestamp | INSTANCE Instance - BEGINNING ALLOCATION 

SUB-PHASE” 


ReadyFile FileID on PeerNodeID is ready for Instance of TaskID on NodeID. This 

event occurs only, if the task writes on this file. 


“realtimestamp | INSTANCE Instance - READY FILE 


log file entries in the file ‘Node/TASKTaskID.access’.


LockingSubPhase Instance of TaskID on NodeID has begun its locking subphase. This 

events occurs only, if the task reads at least one file. 


“realtimestamp | INSTANCE Instance - BEGINNING LOCKING 

SUB-PHASE” 


LockedFile FileID on PeerNodeID is locked by Instance of TaskID on NodeID. 


“realtimestamp | INSTANCE Instance - LOCKED FILE 



GiveBackLock Instance of TaskID on NodeID has given back lock to FileID on 

PeerNodeID. 


“realtimestamp | INSTANCE Instance - GIVEBACK FILE 



RemoveFile FileID on PeerNodeID has been removed and Instance of TaskID on 

NodeID has been notified. 


“realtimestamp | INSTANCE Instance - REMOVE FILE 



ComputationPhase Instance of TaskID on NodeID has begun its computation phase. 


“realtimestamp | INSTANCE Instance - BEGINNING COMPUTATION 

PHASE” 


Reading Instance of TaskID on NodeID has read from FileID on PeerNodeID. 


“realtimestamp | INSTANCE Instance - PLAYER TaskID Instance@Node 

- READING (...)” 


Unlike the e. g. ‘LocatedFile’, ‘LockedFile’ events this log file entry is found in the log 

files of the accessed file, so compared to the preceding events NodeID and PeerNodeID are 

swapped. 

Writing Instance of TaskID on NodeID has written to FileID on PeerNodeID. 


“realtimestamp | INSTANCE Instance - PLAYER TaskID Instance@Node 

- WRITING (...)” 

log file entries in the file ‘Node/TASKTaskID.access’.

26 DATABASE 

Unlike the e. g. ‘LocatedFile’, ‘LockedFile’ events this log file entry is found in the log 

files of the accessed file, so compared to the preceding events NodeID and PeerNodeID are 

swapped. 

Succeeding Instance of TaskID on NodeID is going to terminate successfully. 


“realtimestamp | INSTANCE Instance - SUCCEEDING” 


Failing Instance of TaskID on NodeID could not access the files in time and is not going 

to terminate successfully. 


“realtimestamp | INSTANCE Instance - FAILING” 


Aborting Instance of TaskID on NodeID has been aborted and is not going to terminate 

successfully. 


“realtimestamp | INSTANCE Instance - ABORTING” 


ReleasePhase Instance of TaskID on NodeID has begun its release phase. 


“realtimestamp | INSTANCE Instance - BEGINNING RELEASE 

PHASE” 


ReleaseFile Instance of TaskID on NodeID has released FileID on PeerNodeID. 


“realtimestamp | PLAYER TaskID Instance@PeerNode - RELEASE” 

log file entries in the file ‘Node/FileFileID.access’. 

Unlike the e. g. ‘LocatedFile’, ‘LockedFile’ events this log file entry is found in the log files 

of the accessed file, so compared to those events NodeID and PeerNodeID are swapped. 

Success Instance of TaskID on NodeID has terminated successfully. 


“realtimestamp | INSTANCE Instance - SUCCESS [...]” 


Failed Instance of TaskID on NodeID has terminated not successfully. 


“realtimestamp | INSTANCE Instance - FAILED [...]” 


3.3.9 Logs Table 

The database table ‘EVENTS’ holds all events occuring in all experiments. The table consists of 

the following columns:

3.4 Logfile filter 27 

ExpID SMALLINT 

references an ExpID in the EXPERIMENTS table and assigns this event to one experiment. 

TimeStamp INTEGER 

is the time relative to the first event in the experiment in . 

RealTimeStamp FLOAT 

is the timestamp found in the logfiles in . 

EventID SMALLINT 

references an EventID in the EVENTS table. 

FileID SMALLINT 

references an FileID in the FILES table 


references an NodeID in the NODES IN EXPERIMENT table 

PeerNodeID SMALLINT 

references an NodeID in the NODES IN EXPERIMENT table 

TaskID SMALLINT 

references an TaskID in the TASKS table 

Instance INTEGER 

Criticality SMALLINT 

Sensitivity SMALLINT 

Data INTEGER 

The last eight columns hold the parameters that are mandatory for the event. Constraints 

ensure that the columns are filled with data, if and only if this is intended for the respective 

EventID according to the EVENTS table (s. section 3.3.8). 

3.4 Logfile filter 

The filter program is strictly speaking not a part of this thesis. The perl script was written by 

Wolfgang Freund G. and Frank Thorsten Breuer. 

Its duty is to add a performed experiment to the MELODY database. Therefore it copies all 

MELODY logfiles from the experiment manager brachio to the local host and parses them. 

It adds one row each to the EXPERIMENTS and EXPEXIMENT PARAMS tables and several 

rows to the FILES IN EXPERIMENT, NODES and TASKS tables according to the MELODY 

parameter files. It inserts the required logfile data to the LOGS table in consistence with the 

EVENTS table.

Chapter 4 

Implementation 

The implementaion of the graphical user interface is the second part of the practical work. This 

chapter explaines the choice of Java as programming language. The design of the graphical user 

interface is described and illustrated with UML 1 diagrams. In the following sections interesting 

implementation details concerning the translation of the data, obtained from the database, into 

displayable information are explained. 

4.1 Java 

As programming language C, C++, and Java are in widespread use. Both C and C++ are standard 

languages especially in an UNIX environment. Whereas Java is a quite young object orientated 

language that gained an enormous popularity. 

Before deciding on a language the key requirements to the language are to be considered: 

For the implementation of a graphical user interface the used programming language 

should provide a set of powerful graphic routines. 

The program must be executed with a reasonable speed, since the graphical user interface 

includes animations. 

Multi threaded programming languages deskill graphic animation programming. 

Database access should be provided independently from the database system. 

An object orientated software design is desired. 

Java’s Abstract Windowing Toolkit provides a sufficient set of classes to develop a graphical user 

interface. Additionally the ‘Swing’ classes, a package for developing more advanced graphical 

user interfaces, are available. The ‘Swing’ classes have become a part of the Java standard classes 

in Java version 1.2. 

C and C++ themself do not provide libraries for building graphical user interfaces but use 

external libraries like Motif. Another possibility is to use programs like Tkl/Tk. Using Motif 

produces faster programs compared to Java. Motif provides more features and higher speed 

performance, but using Motif is quite tricky and fault-prone. Tkl/Tk is not faster that Java. The 

combination of two heterogenous systems like C++ and Tkl/Tk causes problems which cannot 

arise when using a monolithic system like Java. 

1 UML = unified modelling language

30 IMPLEMENTATION 

For C and C++ a number of database access libraries exist. Usually these are database 

specific and migration from one database system to another is complicated. The JDBC (Java 

Database Connection) provides a package for operation system independent and database system 

independent access to SQL databases. 

Java itself is multi threaded, while C and C++ have to utilze libraries. C and C++ programs 

are compiled for a special platform. Compiled Java programs are interpreted by the Java Virtual 

Machine and stay platform independent. The consequence is that Java programs cannot reach 

the speed of C or C++ programs. 

Java serves the requirements above. C and C++ have to utilize external libraries to reach the 

functionality of core java. Since C is a procedural language, a decision between C++ and java 

is to be made. Trading-off the functionality of Java and the higher speed of C++ the decision is 

Java. 

The version 1.1.7 of the JDK (Java Development Kit) [2] is used. This version is distributed 

with the S.U.S.E. LINUX distributions [5] as a trade-off between stability and functionality. — 

A comprehendable decision. 

4.2 Software Architecture 

Figure 4.1 gives an overview of all classes created for the graphical user interface. The UML 

figures printed in this chapter were produced using [6]. The graphical user interface contains 

three classes which apear on the screen as independent Frames. Each of them, together with the 

classes the respective class utilizes, makes one module of the graphical user interface. 

ExpSelect 

InfoFrame 

ExpFrame 

Each of these modules is described in the following sections. 

The communication between these modules is done by using the ClosableWindow interface 

that is implemented by each of the classes listed above. 

The one and only instance of the ExpSelect class is instanciated by the public static 

void main() method, where the execution of the program starts. This instance creates instances 

of the InfoFrame and ExpFrame classes depending on the user input. The ExpSelect 

class keeps track of all open windows. It can close one of the windows by calling its 

closeFrame() method. Vice versa the window calls the closeFrame() method of the 

ExpSelect class when closing itself. 

4.3 Experiment Selector 

The ExpSelect class is a subclass of the Frame class. The one and only instance is created 

after the program start. 

This instance establishes a connection to the database. All other classes which need a connection 

call the getConnection() method of this class to obtain one. 

This instance holds a list of all experiments stored in the database. If the user wants an 

experiment to be displayed or wants to see the experiment info, this class instanstantiates the 

ExpFrame resp. the InfoFrame classes. It keeps track of all these instances. If one of these 

frames closes itself, it informs the ExpSelect instance by calling its closeFrame method.

4.3 Experiment Selector 31 

Figure 4.1: All Classes Overview


Figure 4.2: Important Classes in Detail

4.4 Info Frame 33 

4.4 Info Frame 

The InfoFrame class is the smallest module of the graphical user interface. It is a subclass of 

the Frame class. Its only job is to obtain a database connection from the ExpSelect class and 

retrieve the initial file distribution and task parameters. This information is displayed by placing 

instances of the Label class into a Scrollpane. 

When this frame is closing itself, it calls the closeFrame method from the ExpSelect 

class. 

4.5 Experiment Frame 

The most subtle module is the ExpFrame. The ExpFrame class is a subclass of the Frame 

class. After being instantiated itself by the ExpSelect class it chiefly creates its own MenuBar, 

an instance of the ExperimentCanvas class and an instance of the TimerDialog. class 

The TimerDialog instance obtains the required data from the database and transfers it to 

the ExperimentCanvas instance. So most of the work is done by these two classes. 

4.5.1 Experiment Canvas 

This class holds all information about all displayed objects. Therefor the following data structure 

is created. 

Hashtable nodes; 

public class NodeData 

{ 

int id; 

String name; 

... 

Hashtable tasks; 

... 

} 

public class TaskData 

{ 

int nodeID; 

int taskID; 

int crit; 

int sens; 

int yOffset; 

... 

Hashtable instances; 

... 

} 

public class FileAccessData 

{ 

int peerNodeID; 

int fileID;


} 

int status; 

... 

public class InstanceData 

{ 

int nr; 

... 

int status; 

int crit; 

int sens; 

int success; 

Hashtable fileAccess; 

... 

} 

Hashtable files; 

public class FileStatus 

{ 

int copyStatus; 

int moveStatus; 

int movePeer; 

int asgnStatus; 

int lockStatus; 

Hashtable lockPeers; 

... 

} 

class FileData 

{ 

int id; 

... 

Hashtable status; 

... 

} 

The ExperimentCanvas class holds the NodeData in the Hashtable nodes. Each 

NodeData again holds the TaskData in the Hashtable tasks. And again each Task- 

Data holds the InstanceData in the Hashtable instances. 

So the Hashtable nodes contains all data regarding the nodes, the tasks on each node, 

and the instances of each task. 

The other important data structure is the Hashtable files. It holds all FileData, i. e. 

all information about the file distribution, the file servers and file assigner. 

The following methods enlarge these data structures by adding more objects to the respective 

Hashtables. They return true, if the operation was successful, false, otherwise. 

public boolean addNode(int n, String s);

4.5 Experiment Frame 35 

public boolean addFile(int n); 

public boolean addTask(int nodeID, int taskID, int crit, 

int sens); 

public boolean addWriteFile(int nodeID, int taskID, 

int fileID); 

public boolean addTaskInstance(int nodeID, int taskID, 

int instance); 

The following methods change the status of the respective objects. They return true, if the 

event was visible on the screen, false, otherwise. The TimerDialog needs this information 

to stop after every visible event in single step mode. 

public boolean setFileAsgnStatus(int fileID, int nodeID, 

int status); 

public boolean setFileLockStatus(int fileID, int nodeID, 

int status); 

public boolean setFileLockPeer(int fileID, int nodeID, 

int peerNodeID, int status); 

public boolean setTaskInstanceStatus(int nodeID, int taskID, 

int instance, int status); 

public boolean setTaskInstanceCritSens(int nodeID, int taskID, 

int instance, int c, int s); 

public boolean setFileAccessStatus(int nodeID, int taskID, 

int instance, int fileID, int peerNodeID, int status); 

public boolean setTaskInstanceSuccess(int nodeID, int taskID, 

int instance, int status); 

boolean setFileCopyStatus(int fileID, int nodeID, int status); 

boolean setFileMovePeer(int fileID, int nodeID, int peerNodeID); 

boolean setFileMoveStatus(int fileID, int nodeID, int status); 

boolean fileMoveDataPortion(int fileID, int nodeID); 

4.5.2 Timer Dialog 

This class takes the user input regarding the progress in time. For each action ‘to beginning of 

experiment’, ‘one step forward’, ‘ten steps forward’, ‘play’, ‘one step back’, ‘ten steps back’, 

and ‘goto timestamp’ a button is created. If a button is pressed the respective method is called. 

The example below shows invoked, when the ‘play’ button is pressed. 

boolean doPlay(...) 

{ 

ResultSet results = ... /* make SQL query */ 

while(results.next()) 

{ 

if( ... /* display interrupted */) 

{ 

return(true); 

} 

setCurrentTime(results.getInt(9)); 

doStep(results)) 

}


} 

return(false); 

boolean doStep(ResultSet result) 

{ 

switch(result.getInt(1)) 

{ 

case ...: return( ... ); 

/* call ExperimentCanvas.method() */ 

... 

case ...: return( ... ); 

} 

System.err.println("Error: unknown event"); 

return(false); 

} 

The method do step is called for each event. It translates the data recieved from the database 

into calls to the ExperimentCanvas instance.

Chapter 5 

User Manual 

This chapter illustrates the graphical user interface. The functionality of the three modules the 

experiment selector, the experiment frame, and the experiment info frame is described out of a 

user’s point of view. 

5.1 Program Start and Connection to the Database 

The graphical user interface is started by executing the shell script GUI run. The script sets the 

required Java properties and extents the CLASSPATH variable. 

First of all the graphical user interface must connect to the database system. Therefore it 

prompts for the necessary data (see figure 5.1). That is the database URL, the user name, and the 

password, where the database URL has the following form: 

protocol:driver://host:port/database 

The default database URL is set by the above mentioned shell script. 

The input is concluded by pressing the ‘Ok’ button. If the connection to the database connot 

be established the window keeps prompting for the correct input. Pressing the ‘Cancel’ button 

quits the program. As soon as the graphical user interface could connect the experiment selector 

window becomes accessible. 

Figure 5.1: Connecting to the Database

38 USER MANUAL 

5.2 The Experiment Selector 

The experiment selector looks like displayed in figure 5.2. It lists all MELODY experiments 

stored in the database to be selected by the user. Each row in the list consists of a unique 

experiment id, the user who inserted the experiment, the insertion date, and a short description. 

The menu bar grants access to the options of this window. Figure 5.3 shows the menus and 

points out the provided options: 

File Menu figure 5.3(a) 

Figure 5.2: Experiment Selector 

Open Opens the selected experiment in another window (see section 5.3). If no experiment 

is selected or the experiment is already opened, this menu item is disabled. 

This action can also be performed by double clicking the experiment in the list. 

Info Opens an extra window showing the initial file distribution and the files accessed by 

each task (see section 5.4). 

Close Closes this window. 

Quit Closes all windows and quits the graphical user interface. 

View Menu figure 5.3(b) 

Update The experiment selector is not notified about newly inserted experiment. Selecting 

this menu item rereads the list of experiments from the database. 

(a) File Menu (b) View Menu (c) Filter Dialog 

Figure 5.3: Experiment Selector Menu Bar

5.3 The Experiment Window 39 

Order by The listed experiments can be arranged by number, user, date, or description 

each in descending or ascending order. 

Filter . . . Shows the filter dialog (figure 5.3(c)), allowing to list only the desired experiments. 

5.3 The Experiment Window 

The experiment window visualizes all information regarding the file distribution, the file assigner 

activities and the running task instances. The window is divided into columns representing the 

MELODY nodes. At the head of each column the currently existing file copies and the MELODY 

file assigner activities are displayed. Thereunder the tasks on this node are listed. 

The representation of file copies is introduced in section 5.3.1, the representation of the file 

assigner activities in section 5.3.2, and the representation of tasks in section 5.3.4. 

Figure 5.4: Experiment Window 

The menu bar (figure 5.5) gives an overview about the options of this window: 

File Menu figure 5.5(a) 

ExpSelect Shows the experiment selector window, so the user can select another experiment. 

Close Closes this experiment window 

Quit Closes all windows and quits the graphical user interface. 

View Menu figure 5.5(b) 

Timer Hides resp. shows the timer dialog which controls the progress in time while an 

experiment is displayed 

Exp. Parameters Hides resp. shows the parameters dialog 

Assigner Locks Hides resp. shows the lines representing the file assigner locks 

File Access Hides resp. shows the lines representing the task file access 

ViewNode Menu figure 5.5(c) 

Hides resp. shows nodes, i. e. the column representing a node. All events involving this 

node are not displayed. 

ViewFiles Menu figure 5.5(d) 

Hides resp. shows files. Again events involving this file are not displayed.


(a) File (b) View (c) View Node 

(d) View File (e) View Task (f) Options 

Figure 5.5: Experiment Window Menu Bar 

ViewTasks Menu figure 5.5(e) 

Hides resp. shows tasks. Every task on each node can be hidden seperately. 

Options Menu figure 5.5(f) 

Selects a speed for the play mode. 

5.3.1 File Copies 

MELODY provides three qualities of files: public copies, shadow copies, and private copies. 

Figure 5.6 shows the appearance of each type. 

The file distribution is shown at the top of the experiment window. For non existing file 

copies the space is left empty (a neighbouring file does not move up) in order to attain a clear 

arrangement. 

(a) Private Copy (b) Public Copy (c) Public Copy with Shadow 

Copy 

5.3.2 File Assigner 

Figure 5.6: Qualities of File Copies 

The MELODY file assigner tries to improve the task file access by changing the file distribution. 

The file assigner client decisions have already been explained in section 2.3. They are displayed


by the graphical user interface as described in the following. 

Get Public Copy see figure 5.7(a) 

The decision to create a public copy in this node is displayed by the outline of a public 

copy. Its color is green indicating a decision in a non-emergency situation. 

Remove Local Copy see figure 5.7(b) 

The decision to remove either a private or a public local copy is both displayed in the same 

way. It is distinguished by the type of file copy underlying the cross-out. 

Remove Remote Public Copy see figure 5.7(c) 

The decision to reduce the number of public copies is displayed by a thumb pointing down. 

Again this is a non-emergency decision so the colour is green. 

Emergency Remove Public Copy see figure 5.7(d) 

The difference to the above decision is that this decision is made in an emergency situation, 

so it is displayed in red. 

Get Private Copy see figure 5.7(e) 

The decision to create a private copy in this node is displayed by a green outline of a 

private copy. 

Emergency Get Private Copy see figure 5.7(f) 

This decision is made in an emergency situation. Hence the outline of a private copy is 

displayed in red. 

(a) Get Public Copy (b) Remove Local 

Copy 

(d) Emergency Remove 

Public Copy 

(c) Remove Remote 

Public Copy 

(e) Get Private Copy (f) Emergency Get Private 

Copy 

Figure 5.7: File Assigner Procedures 

In case the decision affects the distribution of public copies, the file assigner client has to 

compete for a file assigner lock on this file. Granted locks are displayed by pink arrows pointing 

from the node whose file assigner client obtained the lock to the node whose file assigner server 

granted it. Denied locks are displayed in yellow. In this case a frowny appears at the file assigner 

client’s node (see figure 5.8(a)). 

As described in section 2.3 a file assigner lock may be granted or not. If it is granted, several 

cases may occur:


Lock Granted see figure 5.8(b) 

A file assigner lock on this file has been granted, but the file assigner servers prohibit the 

desired change. 

Lock Granted Move see figure 5.8(c) 

A file assigner lock on this file has been granted. One file assigner server allows to move 

his public copy. 

Lock Granted Copy see figure 5.8(d) 

A file assigner lock on this file has been granted. All file assigner servers allows to create 

an additional public copy. 

Lock Granted Delete see figure 5.8(e) 

A file assigner lock on this file has been granted. All file assigner servers allows to delete 

a public copy. 

(a) Lock Denied (b) Lock Granted (c) Lock Granted Move 

5.3.3 Changes in File Distribution 

(d) Lock Granted Copy (e) Lock Granted 

Delete 

Figure 5.8: File Assigner Locks 

When a MELODY file assigner client has obtained all required file assigner locks, it can change 

the file distribution. Therefor it sends a request to the local file server. The following procedures 

are possible: 

Creation of a Public Copy see figure 5.9(a) 

The file server creates a public copy. 

Creation of a Private Copy see figure 5.9(b) 

The file server creates a private copy. 

Deletion of a Copy see figure 5.9(c) 

The file server deletes a copy. Whether a private or a public copy is deleted, is obvious 

through the underlying icon displaying either a private or a public copy. 

Relocation of a Public Copy The relocation of a public copy is done by creating a copy on the 

destination node and deleting the copy on the source node.


(a) Get Public Copy (b) Create Private Copy (c) Remove Copy 

Figure 5.9: File Assigner Procedures 

The procedure of transfering a data copy is executed as described in the following. 

Request a Data Copy 

The file server requests a data copy from a node that holds a public copy of the file. A blue 

line connects the icons on the source and on the destination node. 

Receive Data Copy see figure 5.10(a) 

The transfer begins. The icon formerly showing an empty box is now half-filled. 

Receive Data Portion 

The transfer of a data portion is displayed by an icon moving along the blue line menioned 

above. 

Receive Copy Complete see figure 5.10(b) 

The transfer is completed. The icon is now almost filled. As soon as the copy is activated 

the icon is completely filled (see figure 5.6(b)). 

5.3.4 Tasks 

(a) Beginning of Transfer (b) Transfer Completed 

Figure 5.10: File Movement 

MELODY tasks run through a life cycle described in section 2.1.3. The following describes how 

this is visualized by the graphical user interface. 

Arrival see figure 5.11(a) 

Before the scheduling phase has begun the task instance is displayed as empty box just 

showing task and instance number. In figure 5.11 instead of instance number and task 

number ‘I’ resp. ‘T’ is plotted. 

Scheduling Phase see figure 5.12 and figure 5.13 

The beginning of the scheduling phase is indicated by highlighting the task icon in colours 

according to its criticality and sensitivity.


(a) Arrived (b) Scheduled (c) Location Phase 

(d) Acquisition Phase (e) Locking Phase (f) Computation Phase 

(g) Succeeding (h) Failing (i) Release Phase 

Figure 5.11: Task Life Cycle 

(a) non-critical (b) critical (c) ess. critical 

Figure 5.12: Criticality 

(a) robust (b) sensitive (c) ess. sensitive 

Figure 5.13: Sensitivity


Scheduled see figure 5.11(b) 

The instance has been scheduled and waits to begin its location phase. 

Location Phase see figure 5.11(c) 

The location phase is depictured by a magnifying glass. Every file copy that is located by 

the instance is connected to the instance icon with a black line. 

Acquisition Phase see figure 5.11(d) 

The acquisition phase is different for reading tasks and writing tasks. 

Reading tasks have only got to obtain read locks. The read locks are displayed by changing 

the black colour for located files into blue. 

Writing tasks run through the allocation and locking subphases corresponding with the 

phases of the delayed insertion protocol [Dan92]. The Allocation Subphase is displayed 

without a different icon compared to the acquisition phase, since the instance enters the 

allocation subphase immediately after beginning its acquisition phase. In contrast to the 

locks of reading tasks the allocated file copies are marked with green lines for writing 

tasks. 

Locking Subphase see figure 5.11(e) 

The locking subphase is entered by writing tasks only. In this last phase of the delayed 

insertion protocol the writing tasks have got to obtain a write locks on the required file 

copies. Write locks are displayed as red lines. 

Computation Phase see figure 5.11(f) 

After obtaining all required locks the instance can enter its computation phase to perform 

its file access. When a locked file copy has been accessed successfully, the red or blue line 

indicating the file lock is turned dark red resp. dark blue. 

Succeeding see figure 5.11(g) 

This is strictly speaking not a phase of the task life cycle. As soon as the instance has 

successfully accessed all files, it was successful. This is depictured by a green smiley. The 

instance starts to release the locked file copies. 

Failing see figure 5.11(h) 

In case the instance will not be able to meet its deadline or the deadline is already expired 

the instance is marked as failing by displaying a red frowny. 

Release Phase see figure 5.11(i) 

A task instance that failed releases its file locks in this phase. The corresponding lines 

disappear.


5.4 The Experiment Info Window 

The experiment info window visualizes the initial file distribution. Underneath every gray bar 

the file copies initially created on this node are itemized. Thereunder small white bars indicate 

the tasks executed on the node. For each task the accessed files are listed. 

When clicking on a file copy, every copy of this file is highlighted. So conflicts in file access 

are easily detected. 

Figure 5.14: Experiment Info Frame

Chapter 6 

Evaluation 

The database is the basis for the graphical user interface. So testing the database took place first. 

Soley the incremental insertion of the events was done simultaneously for the database and the 

TimerDialog class. 

6.1 Database Creation 

The only source of errors in creating the database were the manually created check constraints. In 

the order, the tables reference each other, beginning with the USER and NODES tables one table 

was manually inhabited with data using the POSTGRESQL frontend. The functions that access 

these tables (described in section 3.3) were invoced by hand, to verify their correctness. Next 

step was to insert allowable and undue data to the tables, whose constraints use these functions, 

to check these constraints, and so forth. 

The EVENTS table was inhabited with only a handful of events to test the function in principle. 

The entry of all events was deferred to later on (section 6.3). This was done event by event 

while testing the graphical user interface. 

6.2 Graphical User Interface Implementation 

In the testing phase the greatest lack of the JAVA DEVELOPMENT KIT [2] emerges: the lack 

of a java debugger. It is true that java forces the programmer to write relatively faultless 

code and dumps useful information, if a java program crashes, but debugging only by inserting 

‘System.out.println(...)’ has definitely not been up to date for ages. 

6.2.1 ExpSelect 

The ExpSelect class establishes the connections to the database. Therefore numerous possible 

errors of the database backend were caused to verify the graphical user interface’s behaviour. 

This class keeps track of all other open frames. This feature was tested using dummies for 

the InfoFrame and ExpFrame classes. 

6.2.2 InfoFrame 

A comparison between the MELODY profiles and the presentation of files and tasks renders a 

verification of the filter program parsing the profiles, the proper database tables and the InfoFrame 

class possible.

48 EVALUATION 

6.2.3 ExpFrame 

Most work in the ExpFrame is done by the ExperimentCanvas and TimerDialog classes. 

The ExperimentCanvas class provides methods which are called mainly by the Timer- 

Dialog class. As a first checking these methods were called by a dummy Frame in the order 

the ExpFrame and TimerDialog classes were expected to do so. 

The TimerDialog class, which gets the log data from the database system, was first tested 

on the few events initially inserted into the EVENTS table. The other events were inserted step 

by step as described in section 6.3. 

6.3 Real Logfile Data 

Step by step more events were added to the EVENTS table i. e. to the filter and the LOGS table 

as well as to the TimerDialog class. For each new event the occurence in the logfiles and in 

the LOGS table was compared to the behaviour of the graphical user interface. 

As soon as a convenient set of events had been inserted, the graphical user interface was at 

the fellows’ disposal. This review, the staff to the MELODY project provided, was a great help 

uncovering the graphical user interface’s faults. 

According to the cease of trouble reports during the last fortnight the graphical user interface 

seems to be satisfactory stable.

Chapter 7 

Conclusions and Future Outlook 

The interest in this thesis shown by the staff of the MELODY project points to the fact that there 

is a need for a graphical user interface for studying the order of events in MELODY experiments. 

The graphical user interface has already been used for studying experiments while performing 

the write reported in [WBF01]. 

The complexity mentioned in section 1.1 outcropped in the first phase of this thesis: 

The analysis of the logfile entries, due to the complexity and a lack of documentation, grew into 

a tailsome and time-consuming matter. The logfile entries’ pinpointed meaning, their sequence 

and interrelationship could be understood by analyzing the MELODY source code. 

The results led to the assumption that MELODY produces consistent log files sufficient for 

displaying the file assigner activities, the tasks’ live cycle and file access. This was verified by 

later phases. 

With the aquired knowledge the next phases, the database and graphical user interface design 

could progress more quickly: 

A selection of events, described in section 3.3.8, are enough to render the behaviour sufficing 

the goals (s. section 1.2) of this thesis. The graphical user interface achieves a clear picture of the 

file assigner activities, the tasks’ live cycle and file access. It is a topview showing every node, 

its files and tasks. Distinct icons and colors are used to distinguish public and private copies, the 

different file assigner decisions as well as the phases of the tasks’ live cycle. The criticality and 

sensitivity and the history of tasks are represented by colors. The file access and file assigner 

locks are visualized by colored lines and arrows. Information, which files a task accesses, is 

provided. 

Coherences beween the tasks’ file access and the changes in file distribution become comprehensible. 

In case the displayed information is too much and becomes confusing, in can be limited to the 

information of interest. Every particular node, every particular file and every particular task on 

each node. can easily be hidden. All file access and all file assigner locks can be disessembled. 

The number of events occuring in an experiment depends mainly on the number of tasks as 

well as on the experiment duration and varies between in and in . An average 

experiment produces roughly 500 events per second. In the fastest mode these 500 events can 

be displayed within one minute. So for longer experiments the above mentioned filter should be 

used, too. 

Future work will have to be done to keep the graphical user interface up to consecutive refinements 

to MELODY. Services of new versions of MELODY, e. g. the transactions in [Böh00] (a 

thesis overlapping in time with this thesis), ought to be displayed by the graphical user interface.

50 CONCLUSIONS AND FUTURE OUTLOOK 

Just so the MELODY services, currently not producing logfile data, should be made visual. 

These are e. g. the scheduler and the run-time integtration. 

MELODY requires a huge number of parameters: The initial file distribution, task configuration 

and the strategies for the MELODY services have got to be set. At present these parameters 

are adjusted in ASCII parameter-files. Great pains have to be taken over this fault-prone process. 

The graphical user interface should be upgraded to a control center for creating, configurating, 

running, analyzing, and removing experiments. If the parameters are set in an interactive 

user interface, inconsistencies can be prevented. Settings can be adopted from archieved experiments. 

Prepared experiments can automatically be run several times or at night-time. All told a 

control center like this would be a helpful extension to MELODY.

Used Software 

[1] DEZIGN FOR DATABASES V.2.2 

http://www.heraut.demon.nl/ 

DEZIGN FOR DATABASES is a database design and maintenance tool for database designers 

and programmers. 

[2] JAVA DEVELOPMENT KIT version 1.1.7B 

http://java.sun.com/ 

The Java Development Kit is a development environment for writing applets and applications 

that conform to the Java 1.1 Core API. 

http://java.sun.com/products/jdk/1.1/ 

[3] MYSQL 

http://www.mysql.com/ 

MYSQL is a relational database management system. 

http://www.mysql.com/downloads/ 

[4] POSTGRESQL 

http://www.postgresql.org/ 

POSTGRESQL is a sophisticated Object-Relational DBMS, supporting almost all SQL 

constructs, including subselects, transactions, and user-defined types and functions. 

ftp://ftp.de.postgresql.org/ 

[5] S.U.S.E. LINUX 6.1 

http://www.suse.de/ 

S.U.S.E. LINUX is a distribution of the LINUX operating system. 

ftp://ftp.suse.com/pub/suse/i386/6.1/ 

[6] TOGETHER 4.1 

http://www.togethersoft.com/ 

UML Modelling Tool 

http:://www.togethersoft.com/downloads/

Bibliography 

[AWCD00] David Axmark, Michael Widenius, Jeremy Cole, and Paul DuBois. MySQL Reference 

Manual. http://www.mysql.com/documentation/mysql/bychapter/, 2000. 

[Böh00] Sabine Böhm. Distributed transaction management in safety-critical systems. Master’s 

thesis, University of Dortmund, June 2000. 

[Dan92] Douglas C. Daniels. The Design and Analysis of Protocols for Distributed Resource 

Scheduling under Real-Time Constraints. PhD thesis, Wayne State University, Detroit, 

Michigan, June 1992. 

[DD97] C. J. Date and Hugh Darwen. A Guide to the SQL Standard. Addison-Wesley, 

Reading, Ma., 4. edition, 1997. 

[Fre99] Christian Frey. Entwurf und implementierung einer verteilten experimentierumgebung 

für resource-scheduling-algorithmen. Master’s thesis, Universität Dortmund, 

March 1999. 

[FvDFH92] James D. Foley, Andries van Damm, Steven K. Feiner, and John F. Hughes. Computer 

Graphics, principles and practice. Addision-Wesley Systems Programming 

Series. Addison-Wesley, Reading, Ma., 2. edition, 1992. 

[GK97] Mark Grand and Jonathan Knudsen. Java Fundamental Classes Reference. The 

Java Series. O’Reilly, Sebastopol, 1. edition, July 1997. 

[GMS94] Michel Goossens, Frank Mittelbach, and Alexander Samarin. Der LATEX Begleiter. 

Addison-Wesley (Deutschland), Bonn, 1. edition, 1994. 

[Lin99] Jon A. Lind. Realization of the Highly Integrated Distributed Real-Time Safety- 

Critical System Melody. PhD thesis, University of Dortmund, January 1999. 

[Mom00] Bruce Momjian. PostgreSQL: Introduction and Concepts. to be published by 

Addison-Wesley, version July 2000. 

[OW97] Scott Oaks and Henry Wong. Java Threads. The Java Series. O’Reilly, Sebastopol, 

1. edition, January 1997. 

[Pos00] The PostgreSQL Development Team. PostgreSQL online documentation and FAQs. 

http://www.de.postgresql.org/docs/, 2000. 

[Ree97] George Reese. Database Programming with JDBC and Java. The Java Series. 

O’Reilly, Sebastopol, 1. edition, June 1997. 

[SG94] Abraham Silberschatz and Peter B. Galvin. Operation System Concepts. World 

Student Series. Addison-Wesley, 4. edition, 1994.

54 BIBLIOGRAPHY 

[Sta96] Carsten Stange. Adaptives File Assignment in verteilten sicherheitskritischen Betriebssystemen. 

Master’s thesis, Universität Dortmund, August 1996. 

[vdL98] Peter van der Linden. Just Java and Beyond. Java Series. Sun Microsystems Press, 

Palo Alto, Ca., 3. edition, 1998. 

[WBF01] Horst F. Wedde, Sabine Böhm, and Wolfgang Freund. Adaptive protocols for survivability 

of transaction operation of replicated objects. submitted to the Sixth Int’l 

Workshop on Object-Orientated Real-Time Systems, Rome, Italy, January 2001. 

[WF00] Horst F. Wedde and Wolfgang Freund. Harmonious internal clock synchronization. 

In EUROMICRO Workshop on Real-Time-Systems 2000 (ERTS’00), pages 175 – 

182, Stockholm, Sweden, June 2000. Euromicro, IEEE Computer Society Press. 

[Win81] Józef Winkowski. Protocols of accessing overlaping sets of resources. Information 

Processing Letters, 12(5):239–243, October 1981. 

[WL97] Horst F. Wedde and Jon A. Lind. Building large, complex, distributed safety-critical 

systems. Real-Time Systems, 13(3):277–302, 1997. 

[WLS99] Horst F. Wedde, Jon Lind, and Guido Segbert. Distributed real-time task monitoring 

in the safety-critical system melody. In Proc. of the RTSS 99, 1999. 

[Zuk97] John Zukowski. Java AWT Reference. The Java Series. O’Reilly, Sebastopol, 1 

edition, January 1997.

Appendix A 

Database 

A.1 Creation 

1 /************************************************************* 

* create_db_melody.sql * 

* * 

* creates all tables functions, ... needed for melody * 

5 *************************************************************/ 

/*************************************************************/ 

CREATE TABLE USERS 

( 

10 UserID SMALLINT NOT NULL UNIQUE PRIMARY KEY, 

Name VARCHAR(30) NOT NULL UNIQUE, 


); 

15 /* userOK(UserID) 

* -> 0: UserID does not exist 

* -> 1: UserID exists */ 

CREATE FUNCTION userOk(SMALLINT) 

RETURNS INTEGER 

20 AS ’SELECT COUNT(UserID) FROM USERS WHERE UserID = $1;’ 

LANGUAGE ’sql’; 

/* current_userID() 

* -> UserID of current user */ 

25 CREATE FUNCTION current_userID() 

RETURNS SMALLINT 

AS ’SELECT UserID FROM USERS WHERE name = CURRENT_USER;’ 


30 /*************************************************************/ 

CREATE TABLE NODES 

( 

NodeID SMALLINT NOT NULL UNIQUE PRIMARY KEY, 

Name VARCHAR(20) NOT NULL, 

35 Ok BOOLEAN NOT NULL DEFAULT TRUE 

); 

/* nodeOK(NodeID)

56 DATABASE 

* -> 0: NodeID does not exist 

40 * -> 1: NodeID exists */ 

CREATE FUNCTION nodeOk(SMALLINT) 


AS ’SELECT COUNT(NodeID) FROM NODES WHERE NodeID = $1;’ 


45 

/*************************************************************/ 

CREATE TABLE EXPERIMENTS 

( 

ExpID INTEGER NOT NULL UNIQUE PRIMARY KEY, 

50 UserID SMALLINT NOT NULL CHECK (userOk(UserID) > 0) 

DEFAULT current_userId(), 

DateTime TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 


); 

55 

/* expOK(ExpID) 

* -> 0: ExpID does not exist 

* -> 1: ExpID exists */ 

CREATE FUNCTION expOk(SMALLINT) 

60 RETURNS INTEGER 

AS ’SELECT COUNT(ExpID) FROM EXPERIMENTS WHERE ExpID = $1;’ 


/*************************************************************/ 

65 CREATE TABLE NODES_IN_EXPERIMENT 

( 

ExpID INTEGER NOT NULL CHECK (expOk(ExpID) > 0), 

NodeID SMALLINT NOT NULL CHECK (nodeOk(NodeID) > 0) 

); 

70 

CREATE UNIQUE INDEX NODES_IN_EXP 

ON NODES_IN_EXPERIMENT (ExpID, NodeID); 

/* nodeInExp(ExpID, NodeID) 

75 * -> 0: node NodeID takes part in exp. ExpID 

* -> 1: node NodeID does not take part in exp. ExpID */ 

CREATE FUNCTION nodeInExp(INTEGER, SMALLINT) 


AS ’SELECT COUNT(*) FROM NODES_IN_EXPERIMENT 

80 WHERE ExpID = $1 AND NodeID = $2;’ 


/*************************************************************/ 

CREATE TABLE SCHINTEGRATION 

85 ( 

SchIntegID SMALLINT NOT NULL PRIMARY KEY, 

Abr CHAR (1) NOT NULL, 

Description VARCHAR (50) 

); 

90 

/* schOk(SchIntegID) 

* -> 0: Scheduler integration type not defined 

* -> 1: Scheduler integration type defined */

A.1 Creation 57 

CREATE FUNCTION schOk(SMALLINT) 


AS ’SELECT COUNT(*) FROM SCHINTEGRATION 

WHERE SchIntegID = $1;’ 


100 /*************************************************************/ 

CREATE TABLE RTINTEGRATION 

( 

RTIntegID SMALLINT NOT NULL PRIMARY KEY, 


105 Description VARCHAR (50) 

); 

/* rtiOk(RTIntegID) 

* -> 0: Run time integration type not defined 

110 * -> 1: Run time integration type defined */ 

CREATE FUNCTION rtiOk(SMALLINT) 


AS ’SELECT COUNT(*) FROM RTINTEGRATION 

WHERE RTIntegID = $1;’ 

115 LANGUAGE ’sql’; 

/*************************************************************/ 

CREATE TABLE FAINTEGRATION 

( 

120 FAIntegID SMALLINT NOT NULL PRIMARY KEY, 



); 

125 /* faiOk(FAIntegID) 

* -> 0: File assigner integration type not defined 

* -> 1: File assigner integration type defined */ 

CREATE FUNCTION faiOk(SMALLINT) 


130 AS ’SELECT COUNT(*) FROM FAINTEGRATION 

WHERE FAIntegID = $1;’ 


/*************************************************************/ 

135 CREATE TABLE FILEMODELS 

( 

FileModelID SMALLINT NOT NULL PRIMARY KEY, 

Abr VARCHAR (7) NOT NULL, 


140 ); 

/* filemodelOk(FileModelID) 

* -> 0: File model not defined 

* -> 1: File model defined */ 

145 CREATE FUNCTION filemodelOk(SMALLINT) 


AS ’SELECT COUNT(*) FROM FILEMODELS 

WHERE FileModelID = $1;’

58 DATABASE 


150 

/*************************************************************/ 

CREATE TABLE EXPERIMENT_PARAMS 

( 

ExpID INTEGER NOT NULL CHECK (ExpOK(ExpID) > 0), 

155 Critical SMALLINT NOT NULL DEFAULT 10, 

EssCritical SMALLINT NOT NULL DEFAULT 3, 

Sensitive SMALLINT NOT NULL DEFAULT 10, 

EssSensitive SMALLINT NOT NULL DEFAULT 5, 

SchIntegID SMALLINT NOT NULL DEFAULT 2 

160 CHECK (SchOk(SchIntegID) > 0), 

SchParams VARCHAR (20) NOT NULL DEFAULT ’(1|3,1,4)’, 

RTIntegID SMALLINT NOT NULL DEFAULT 3 

CHECK (RTIOk(RTIntegID) > 0), 

FAIntegID SMALLINT NOT NULL DEFAULT 2 

165 CHECK (FAIOk(FAIntegID) > 0), 

FAThNotUsed SMALLINT NOT NULL DEFAULT 0, 

FAThGetCopy SMALLINT NOT NULL DEFAULT 2, 

FAThAllowCopy SMALLINT NOT NULL DEFAULT 10, 

FAThReduceCopy SMALLINT NOT NULL DEFAULT 2, 

170 FAThDeleteCopy SMALLINT NOT NULL DEFAULT 2, 

FATryWait SMALLINT NOT NULL DEFAULT 400, 

FAChangeWait SMALLINT NOT NULL DEFAULT 1000, 

FAHistWindow SMALLINT NOT NULL DEFAULT 5000, 

FileModelID SMALLINT NOT NULL DEFAULT 1 

175 CHECK (filemodelOk(FileModelID) > 0), 

MinPublic SMALLINT NOT NULL DEFAULT 1, 

MaxPublic SMALLINT NOT NULL DEFAULT 7, 

ServerPrio SMALLINT NOT NULL DEFAULT 55, 

SyncMaster SMALLINT NOT NULL DEFAULT 4 

180 CHECK (NodeInExp(ExpID, SyncMaster) > 0) 

); 

/*************************************************************/ 

CREATE TABLE FILES 

185 ( 

ExpID INTEGER NOT NULL, 

FileID INTEGER NOT NULL, 

NodeID SMALLINT NOT NULL, 

Type CHAR(4) NOT NULL CHECK (Type IN (’PRIV’, ’PUB’)), 

190 Description VARCHAR(120), 

CHECK (nodeInExp(ExpID, NodeID) > 0) 

); 

CREATE UNIQUE INDEX FILES_IN_EXP ON FILES (ExpID, NodeID, FileID); 

195 

/* fileInExp(ExpID, FileID) 

* -> 0: file FileID takes part in exp. ExpID 

* -> 1: file FileID does not take part in exp. ExpID */ 

CREATE FUNCTION fileInExp(INTEGER, SMALLINT) 


AS ’SELECT COUNT(*) FROM FILES 

WHERE ExpID = $1 AND FileID = $2;’ 

LANGUAGE ’sql’;


205 /*************************************************************/ 

CREATE TABLE TASKS 

( 

ExpID INTEGER NOT NULL, 

TaskID SMALLINT NOT NULL, 

210 NodeID SMALLINT NOT NULL, 

Criticality SMALLINT NOT NULL, 

Sensitivity SMALLINT NOT NULL, 

FileID SMALLINT NOT NULL, 

ReadWrite CHAR(1) NOT NULL CHECK (ReadWrite IN (’W’, ’R’)), 

215 CHECK (nodeInExp(ExpID, NodeID) > 0), 

CHECK (fileInExp(ExpID, FileID) > 0) 

); 

CREATE UNIQUE INDEX TASKS_IN_EXP ON TASKS (ExpID, NodeID, TaskID, 

220 FileID, ReadWrite); 

/* taskInExp(ExpID, TaskID, NodeID) 

* -> 0: file FileID takes part in exp. ExpID 

* -> 1: file FileID does not take part in exp. ExpID */ 

225 CREATE FUNCTION taskInExp(INTEGER, SMALLINT, SMALLINT) 


AS ’SELECT COUNT(*) FROM TASKS 

WHERE ExpID = $1 AND TaskID = $2 AND NodeID = $3;’ 


230 

/*************************************************************/ 

CREATE TABLE EVENTS 

( 

EventID SMALLINT NOT NULL UNIQUE PRIMARY KEY, 

235 Abr VARCHAR(30) UNIQUE NOT NULL, 

Description VARCHAR(80) NOT NULL, 

/* Information a log file parser needs */ 

LogFilePattern VARCHAR(80) NOT NULL, 

LogFileType VARCHAR(12) NOT NULL, 

240 LogFileMulti BOOL NOT NULL, 

FileID BOOL NOT NULL, 

NodeID BOOL NOT NULL, 

PeerNodeID BOOL NOT NULL, 

TaskID BOOL NOT NULL, 

245 Instance BOOL NOT NULL, 

Criticality BOOL NOT NULL, 

Sensitivity BOOL NOT NULL, 

Data BOOL NOT NULL 

); 

250 

/* eventIDOk(EventID) 

* -> 0: EventID does not exist 

* -> 1: EventID exists */ 

CREATE FUNCTION eventIDOk(SMALLINT) 


AS ’SELECT COUNT(*) FROM EVENTS 

WHERE EventID = $1;’ 

LANGUAGE ’sql’;

60 DATABASE 

260 /* fileIDMand(EventID) 

* -> 0: FileID entry is manadtory for EventID 

* -> 1: FileID entry is not allowed fot EventID */ 

CREATE FUNCTION fileIDMand(SMALLINT) 


265 AS ’SELECT COUNT(*) FROM EVENTS WHERE EVENTID = $1 

AND FileID = TRUE’ 


/* nodeIDMand(EventID) 

270 * -> 0: NodeID entry is manadtory for EventID 

* -> 1: NodeID entry is not allowed fot EventID */ 

CREATE FUNCTION nodeIDMand(SMALLINT) 


AS ’SELECT COUNT(*) FROM EVENTS WHERE EVENTID = $1 

275 AND NodeID = TRUE’ 


/* peerNodeIDMand(EventID) 

* -> 0: PeerNodeID entry is manadtory for EventID 

280 * -> 1: PeerNodeID entry is not allowed fot EventID */ 

CREATE FUNCTION peerNodeIDMand(SMALLINT) 



AND PeerNodeID = TRUE’ 


/* taskIDMand(EventID) 

* -> 0: TaskID entry is manadtory for EventID 

* -> 1: TaskID entry is not allowed fot EventID */ 

290 CREATE FUNCTION taskIDMand(SMALLINT) 



AND TaskID = TRUE’ 


295 

/* instanceMand(EventID) 

* -> 0: Instance entry is manadtory for EventID 

* -> 1: Instance entry is not allowed fot EventID */ 

CREATE FUNCTION instanceMand(SMALLINT) 



AND Instance = TRUE’ 


305 /* critMand(EventID) 



CREATE FUNCTION critMand(SMALLINT) 


310 AS ’SELECT COUNT(*) FROM EVENTS WHERE EVENTID = $1 

AND Criticality = TRUE’ 

LANGUAGE ’sql’;


/* sensMand(EventID) 

315 * -> 0: Instance entry is manadtory for EventID 


CREATE FUNCTION sensMand(SMALLINT) 



320 AND Sensitivity = TRUE’ 


/* dataMand(EventID) 


325 * -> 1: Instance entry is not allowed fot EventID */ 

CREATE FUNCTION dataMand(SMALLINT) 



AND Data = TRUE’ 


/*************************************************************/ 

CREATE TABLE LOGS 

( 

335 ExpID INTEGER NOT NULL CHECK (expOk(ExpID) > 0), 

TimeStamp INTEGER NOT NULL, 

RealTimeStamp FLOAT NOT NULL, 

EventID SMALLINT NOT NULL CHECK (eventIDOk(EventID) > 0), 

FileID SMALLINT CHECK ((FileID IS NULL 

340 AND fileIDMand(EventID) = 0) 

OR (fileInExp(ExpID, FileID) > 0 

AND fileIDMand(EventID) > 0)), 

NodeID SMALLINT CHECK ((NodeID IS NULL 

AND nodeIDMand(EventID) = 0) 

345 OR (nodeInExp(ExpID, NodeID) > 0 

AND nodeIDMand(EventID) > 0)), 

PeerNodeID SMALLINT CHECK ((PeerNodeID IS NULL 

AND peerNodeIDMand(EventID) = 0) 

OR (nodeInExp(ExpID, PeerNodeID) > 0 

350 AND peerNodeIDMand(EventID) > 0)), 

TaskId SMALLINT CHECK ( (TaskID IS NULL 

AND taskIDMand(EventID) = 0) 

OR ((taskInExp(ExpID, TaskID, NodeID) > 0 

OR taskInExp(ExpID, TaskID, 

355 PeerNodeID) > 0) 

AND taskIDMand(EventID) > 0) ), 

Instance INTEGER CHECK ((Instance IS NULL 

AND instanceMand(EventID) = 0) 

OR instanceMand(EventID) > 0), 

360 Criticality SMALLINT CHECK ((Criticality IS NULL 

AND critMand(EventID) = 0) 

OR critMand(EventID) > 0), 

Sensitivity SMALLINT CHECK ((sensitivity IS NULL 

AND sensMand(EventID) = 0) 

365 OR sensMand(EventID) > 0), 

Data INTEGER CHECK ((Data IS NULL 

AND dataMand(EventID) = 0) 

OR dataMand(EventID) > 0)

62 DATABASE 

370 

); 

CREATE INDEX TimeInExp ON LOGS (ExpID,TimeStamp); 

/************************************************************* 

* the following functions are for inserting new experiemnts * 

375 * and are used by the logfile filter * 

*************************************************************/ 

/* maxExpID() 

* -> returns the max expID in experiments 

380 * (has side effects unless used prior newExp) */ 

CREATE FUNCTION maxExpID() 


AS ’DELETE FROM EXPERIMENTS WHERE ExpID = 0; 

INSERT INTO EXPERIMENTS (ExpID) VALUES (0); 

385 SELECT MAX(ExpID) FROM EXPERIMENTS;’ 


/* Inserts a new Experiment into table experiments 

* newExpID(Description) 

390 * -> returns the new ExpID */ 

CREATE FUNCTION newExp(VARCHAR) 


AS ’INSERT INTO EXPERIMENTS (ExpID, Description) 

VALUES (maxExpID()+1, $1); 

395 DELETE FROM EXPERIMENTS WHERE ExpID = 0; 

SELECT MAX(ExpID) FROM EXPERIMENTS;’ 


/* Inserts a new Experiment into table experiments 

400 * newExpID(Description, UserID, Timestamp) 

* -> returns the new ExpID */ 

CREATE FUNCTION newExp(VARCHAR, SMALLINT, TIMESTAMP) 


AS ’INSERT INTO EXPERIMENTS 

405 (ExpID, Description, UserId, DateTime) 

VALUES (maxExpID()+1, $1, $2, $3); 

DELETE FROM EXPERIMENTS WHERE ExpID = 0; 

SELECT MAX(ExpID) FROM EXPERIMENTS;’ 


410 /* Deletes an Experiment completely */ 

* deleteExp(ExpID) 

* -> alway returns 0 */ 

CREATE FUNCTION deleteExp(INTEGER) 


415 AS ’DELETE FROM LOGS WHERE ExpID = $1; 

DELETE FROM TASKS WHERE ExpID = $1; 

DELETE FROM FILES WHERE ExpID = $1; 

DELETE FROM NODES_IN_EXPERIMENT WHERE ExpID = $1; 

DELETE FROM EXPERIMENTS WHERE ExpID = $1; 

420 SELECT 0 AS OK;’ 

LANGUAGE ’sql’;

A.2 Events table 63 

A.2 Events table 

1 DELETE FROM EVENTS; 

INSERT INTO EVENTS VALUES (1100, ’GetPublic’, 

’local decision to try to create a local public copy’, 

5 ’GET PUBLIC COPY%’, ’moving’, FALSE, 

TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (1101, ’RemovePublicLocal’, 

’local decision to try to create a local public copy’, 

’REMOVE PUBLIC COPY LOCAL%’, ’moving’, FALSE, 

10 TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (1102, ’RemovePublicRemote’, 

’local decision to try to remove a local public copy’, 

’REMOVE PRIVATE COPY REMOTE%’, ’moving’, FALSE, 


15 INSERT INTO EVENTS VALUES (1103, ’RemoveEmergencyPublic’, 

’local emergency decision to remove a remote public copy’, 

’EMERGNCY PUBLIC%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1104, ’GetPrivate’, 

20 ’local decision to create a local private copy’, 

’GET PRIVATE COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1105, ’GetEmergencyPrivate’, 

’local emergency decision to create a local private copy’, 

25 ’EMERGNCY PRIVATE COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1106, ’RemovePrivate’, 

’local decision to remove a local private copy’, 

’REMOVE PRIVATE COPY LOCAL%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1110, ’LockDenied’, 

’remote file assigner denied lock’, 

’LOCK DENIED%’, ’moving’, FALSE, 

TRUE, TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE); 

35 INSERT INTO EVENTS VALUES (1111, ’LockGranted’, 

’remote file assigner granted lock’, 

’LOCK GRANTED%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1112, ’LockWinnerDeny’, 

40 ’all remote fa granted locks but refuse the requested action’, 

’REQUEST DENIED HISTORY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1113, ’LockWinnerMove’, 

’all remote f a granted lock, at least one allows 

to move his copy’, 

45 ’MOVING PUBLIC FROM%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1114, ’LockWinnerCopy’, 

’all remote fa granted lock and allow to create 

a new copy’, 

’GETTING PUBLIC FROM%’, ’moving’, FALSE, 

50 TRUE, TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE);

64 DATABASE 

INSERT INTO EVENTS VALUES (1115, ’LockWinnerDelete’, 

’all remote fa granted lock, one allows 

to delete his copy’, 

’REMOVING PUBLIC AT%’, ’moving’, FALSE, 


55 INSERT INTO EVENTS VALUES (1116, ’LockWinnerEmergencyRemovePublic’, 

’all remote file assigners granted lock to remove a public 

copy’, 

’EMERGNCY PUBLIC FROM%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1117, ’LockRelease’, 

60 ’release lock at remote file assigner’, 

’LOCK PUBLIC RECEIVE WRITE/ASSIGN%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1200, ’CreatePrivateCopy’, 

’start creating a private copy’, 

65 ’CREATE PRIVATE COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1201, ’CreatePublicCopy’, 

’start creating a public copy’, 

’CREATE PUBLIC COPY%’, ’moving’, TRUE, 


INSERT INTO EVENTS VALUES (1202, ’ChangePrivatePublicCopy’, 

’start creating a public copy out of private one’, 

’CHANGING PRIVATE COPY%’, ’moving’, TRUE, 


75 INSERT INTO EVENTS VALUES (1203, ’DeletePrivateCopy’, 

’start deleteing a private copy’, 

’DELETE PRIVATE COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1204, ’DeletePublicCopy’, 

80 ’start deleting a public copy’, 

’DELETE PUBLIC COPY%’, ’moving’, TRUE, 


INSERT INTO EVENTS VALUES (1205, ’ActivePublicCopy’, 

’public copy created’, 

85 ’ACTIVE PUBLIC COPY%’, ’moving’, TRUE, 


INSERT INTO EVENTS VALUES (1206, ’ActiveShadowCopy’, 

’shadow copy created’, 

’ACTIVATE SHADOW COPY%’, ’update’, FALSE, 


INSERT INTO EVENTS VALUES (1207, ’ActivePrivateCopy’, 

’private copy created’, 

’ACTIVE PRIVATE COPY%’, ’moving’, FALSE, 


95 INSERT INTO EVENTS VALUES (1208, ’DeactivePublicCopy’, 

’public copy deleted’, 

’DEACTIVE PUBLIC COPY%’, ’moving’, TRUE, 


INSERT INTO EVENTS VALUES (1209, ’DeactivePrivateCopy’, 

100 ’private copy deleted’, 

’DEACTIVE PRIVATE COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1300, ’RequestDataCopy’,


’ask foreign node to send a copy’, 

105 ’REQUEST DATA COPY%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1301, ’ReceivePublicCopy’, 

’start receiving a public copy’, 

’RECEIVE COPY PUBLIC%’, ’moving’, FALSE, 


INSERT INTO EVENTS VALUES (1302, ’ReceivePrivateCopy’, 

’start receiving a private copy’, 

’RECEIVE COPY PRIVAT%’, ’moving’, FALSE, 


115 INSERT INTO EVENTS VALUES (1303, ’ReceiveCopyLength’, 

’receive length of data copy’, 

’RECEIVE COPY LENGTH%’, ’moving’, FALSE, 

TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE, TRUE); 

INSERT INTO EVENTS VALUES (1304, ’ReceiveDataPortion’, 

120 ’receive a portin of data’, 

’RECEIVE DATA PORTIO%’, ’moving’, FALSE, 

TRUE, TRUE, FALSE, FALSE, FALSE, FALSE, FALSE, TRUE); 

INSERT INTO EVENTS VALUES (1305, ’ReceiveCopyComplete’, 

’receive length of data copy’, 

125 ’RECEIVE COPY COMPLE%’, ’moving’, FALSE, 


/* TASKS */ 

INSERT INTO EVENTS VALUES (2000, ’InstanceArrival’, 

130 ’task instance has arrived’, 

’INSTANCE ARRIVA%’, ’access’, FALSE, 

FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2001, ’SchedulePhase’, 

’beginning of schedule phase’, 

135 ’BEGINNING SCHED%’, ’access’, FALSE, 

FALSE, TRUE, FALSE, TRUE, TRUE, TRUE, TRUE, FALSE); 

INSERT INTO EVENTS VALUES (2002, ’Scheduled’, 

’end of schedule phase’, 

’SCHEDULED%’, ’access’, FALSE, 

140 FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2003, ’LocationPhase’, 

’beginning of location phase’, 

’BEGINNING LOCAT%’, ’access’, FALSE, 


145 INSERT INTO EVENTS VALUES (2004, ’LocatedFile’, 

’found file on node’, 

’LOCATED FILE%’, ’access’, FALSE, 

TRUE, TRUE, TRUE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2005, ’AquisionPhase’, 

150 ’beginning of aquision phase’, 

’BEGINNING AQUIS%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2006, ’AllocationSubPhase’, 

’beginning of allocation phase (write tasks only)’, 

155 ’BEGINNING ALLOC%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2007, ’ReadyFile’, 

’file on node ready (write tasks only’,

66 DATABASE 

’READY FILE%’, ’access’, FALSE, 

160 TRUE, TRUE, TRUE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2008, ’LockingSubPhase’, 

’beginning of locking phase (write tasks only)’, 

’BEGINNING LOCKI%’, ’access’, FALSE, 


165 INSERT INTO EVENTS VALUES (2009, ’LockedFile’, 

’file on node locked’, 

’LOCKED FILE%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2010, ’ComputationPhase’, 

170 ’beginning of computation phase’, 

’BEGINNING COMPU%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2011, ’Reading’, 

’task instance is reading file’, 

175 ’%READING%’, ’update’, FALSE, 


INSERT INTO EVENTS VALUES (2012, ’Succeeding’, 

’task instance was successful’, 

’SUCCEEDING%’, ’access’, FALSE, 

180 FALSE, TRUE, FALSE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2013, ’Aborting’, 

’decision to abort task instance’, 

’ABORTING%’, ’access’, FALSE, 


185 INSERT INTO EVENTS VALUES (2020, ’Failing’, 

’task instance failed to access files’, 

’ABORTING%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2014, ’ReleasePhase’, 

190 ’beginning of release phase’, 

’BEGINNING RELEA%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2015, ’ReleaseFile’, 

’task instance released locked file’, 

195 ’%- RELEASE%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2015, ’ReleaseFile’, 

’task instance released locked file’, 

’%- RELEASE%’, ’access’, FALSE, 

200 TRUE, TRUE, TRUE, TRUE, TRUE, FALSE, FALSE, FALSE); 

INSERT INTO EVENTS VALUES (2016, ’Success’, 

’task instance released locked files’, 

’SUCCESS%’, ’access’, FALSE, 


205 INSERT INTO EVENTS VALUES (2017, ’Failed’, 

’task instance released locked files’, 

’FAILED%’, ’access’, FALSE, 


INSERT INTO EVENTS VALUES (2018, ’Writing’, 

210 ’task instance writes on file’, 

’%WRITING%’, ’update’, FALSE, 


INSERT INTO EVENTS VALUES (2019, ’GiveBackLock’,


’task instance gives back file lock’, 

215 ’GIVEBACK%’, ’access’, FALSE, 

TRUE, TRUE, TRUE, TRUE, TRUE, FALSE, FALSE, FALSE);

Appendix B 

Source Code and Installation 

All practical work has been done on salbei.cs.uni-dortmund.de. The source is found 

in the folder /home/melody/gui/source. 

The class files have been generated by compiling the ExpSelect.java file. All class files 

have been packed into a Java archive file /home/melody/lib/fagui.jar. The gif files 

used by the graphical user interface live in /home/melody/lib/gifs/. 

The shell script GUI run that starts the graphical user interface is found in 

/home/melody/lib/bin/. 

1 #!/bin/tcsh 

5 

# add the postgres driver to CLASSPATH 

setenv CLASSPATH /usr/lib/pgsql/lib/postgresql.jar:$CLASSPATH 

# add the program classes to CLASSPATH 

setenv CLASSPATH /home/melody/gui/lib/fagui.jar:$CLASSPATH 

#"jdbc.drivers" selects the jdbc driver 

10 #"melody.gifspath" points folder with the required gif files 

java -Djdbc.drivers=postgresql.Driver 

-Dmelody.gifspath=/home/melody/gui/lib/gifs/ ExpSelect

Appendix C 

Sample Pictures 

The pictures on the next two pages give an impression of the graphical user interface. 

The interesting points are: 

FILE25@maia 

The picture on the next page shows the file assigner client has decided to create a local 

public copy. On the next but one page the file assigner client has won the file assigner lock 

shown by the pink arrow and is allowed to move a copy. The transfer has already begun 

indicated by the blue line and the half-filled icon. 

FILE20@titano 

The file assigner client has decided to remove his local copy. The file assigner lock has 

been granted by the file assigner server on titano, while the file assigner client is still 

waiting for a response from plateo. 

TASK1@titano 

On the next but one page this task is in its locking subphase. FILE20@titano is still ready 

while FILE20@plateo is already locked. 

TASK25@maia, TASK27@maia 

On the next but one page the last two instances of TASK25 have failed, the last two instaces 

of TASK27 have succeeded. This is indicated by the two red resp. green dots. The yellow 

dots underneath them show that all these instances have been critical and sensitive.

Diplomarbeit

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?