modules can be physically located on the same 
machine as the other server modules, or they can run 
on specialized machines connected to the server 
through a LAN. 
3.1 Delta-X Server Modules 
The Transaction Monitor module performs transac- 
tion management tasks, such as transaction schedul- 
ing, transaction monitoring, authentication of 
transaction requests, locking of data (see Section 
3.2), resource administration, and transaction com- 
mits, aborts and recoveries. The Transaction Moni- 
tor receives requests for new transactions from 
Delta-X clients or requests to process already run- 
ning transactions from fellow servers in the Delta-X 
federation. The Delta-X server first validates the 
requestor's permissions for accessing the requested 
data and, if successful, it allocates resources for exe- 
cuting of the transaction and starts the transaction. 
The Transaction Monitor also notifies clients about 
the status of transactions in progress, finished trans- 
actions, or aborted transactions. The Transaction 
Monitor also logs accounting data in order to sup- 
port billing of users who access data stored in the 
federation. 
If required, the Transaction Monitor will relocate the 
transaction to another server, for example, to per- 
form a conversion or finish a data transfer. After the 
data conversion has been finished, the Transaction 
Monitor will initiate the transfer of converted data, 
temporarily stored on the server, to its final destina- 
tion, specified by the Delta-X client when the trans- 
action was started. The data transfer itself is 
performed by the Data Mover module. 
The Convertor modules perform data conversions 
from any GIS format into the internal Delta-X data 
format and vice versa. There is one Convertor mod- 
ule for the conversion of each GIS data format to 
and from the Delta-X internal data format. All Con- 
vertors are database and GIS dependent because 
they manipulate data directly. 
The Data Mover module is responsible for sending 
or receiving data between the clients and servers 
and/or between the servers themselves. It is imple- 
mented on top of the TCP/IP protocol stack. 
358 
3.2 Delta-X Server Operation 
The Delta-X server is started by when the operating 
system boots up. After starting up and initializing tg 
communication and authentication tables, the server 
is ready to accept requests from clients. 
Each Delta-X client calls a Delta-X server with a 
request to initiate a transaction (see Figure 3). The 
information sent in the request contains: Delta-X cli- 
ent's identification, description of the transaction, 
location and format of the source (in case of data 
import to Delta-X) or destination (in case of data 
export) data. After a successful authentication of the 
user which started the Delta-X client and of the type 
of the request, the Delta-X server sends an acknowl- 
edgment to the requesting Delta-X client and then 
starts processing the user's request (see Figure 3). 
In the request, the data being accessed in the transac- 
tion may be locked, in which case the read and/or 
write access to the data (as specified in the lock 
request) is disabled for other users until the data is 
unlocked. 
Delta-X supports three types of read transactions: 
normal read which only allows access to unlocked 
data, "dirty" read which allows read access to 
unlocked and write-locked data, and check-out read 
which can read and lock unlocked data. 
Delta-X supports two types of write transactions: 
add which adds new data and check-in which modi- 
fies existing data. Data check-in always creates a 
new version of the data, and is allowed only if the 
data were checked-out by the same user. Older, no 
longer needed versions of data must be deleted man- 
ually by the owner of the data. 
If two or more transactions access the same data, 
Delta-X will queue all transactions following a write 
transaction. Delta-X will also queue all write trans- 
actions, if any transaction in process accesses the 
requested data. Read transactions can proceed con- 
currently. 
The Delta-X client is kept informed about the status 
of its transaction in two ways: 
1. The Delta-X server sends status messages at 
important check-points during the progress of the 
transaction. The client displays status messages 
from the server so that the user is informed about 
the status of the transaction so that the user can 
  
  
Figure 3: 
make de 
transacti 
format c 
plete ev 
2. The Del 
tions the 
À single D 
Delta-X cli 
can start m: 
Current im 
share the s 
ture, howe