Environment

Home	Starting	Environment	DBMS	VisualPQL	Procedures	SQL	Forms	Host/API	Index

Environment

Concurrency

Multiple users can work on the same database at the same time, providing they are not updating it. A database is protected against accidental updating by two separate users at the same time and a second update process is not given access.

If you need multiple processes to update a database at the same time, use MASTER. This is an independent process that controls updates ensuring that the same record cannot be updated by more than one person at the same time. This means that multiple programs can be running at the same time, and all of the updates they perform are coordinated.

The clients request concurrent update operations to a database through a central MASTER.

To make a client use MASTER, first start MASTER (see Running Master) and then start the client SirFORMS, SirSQL or SIR/XS session with the MST = execution parameter. These then pass all requests for data to MASTER. During a SIR/XS session, you can turn the use of Master on and off as necessary. You can do this through the Master Settings menu or with the SET MASTER/CLEAR MASTER commands. It is much faster to retrieve data from the database directly rather than through Master, so it is good practice to turn off Master when using retrievals that do no updating.

A client has an open connection to Master but only has databases attached while a VisualPQL program or SQL retrieval is running that uses them. In Forms, where a database is accessed interactively a record at time, the database is open and in use while the form is active. A database is only in use while the client is accessing it. A MASTER process does not access any database simply by being started.

While a client is using MASTER to access a database, the database is locked against update access by any other process. The database can only be updated through MASTER. If a database is opened in update mode without going through MASTER, the database is locked from access by any other process for the duration of that update.

There are three parts of a database that a process has to access, the dictionary, the procedure file and the data. MASTER only provides concurrent access to the data. Thus all client processes need access to the dictionary and procedure files and so must be able to access the database directly through the network as well as using MASTER.

While MASTER is connected to a database, there are certain things that cannot be done to it

The schema cannot be changed;
Utilities such as UNLOAD/RELOAD cannot be run;
Batch data input utilities cannot be used.

All of these facilities must be run independently of any other processes and require exclusive access to a database.

Multiple Master/Clients/Databases

The concurrent processing environment can include multiple MASTER servers, multiple databases, and multiple client processes. Each MASTER server has the capability of being accessed by many client processes and accessing many databases. A given database may be opened by only one MASTER:

A database can be connected to only one MASTER at a time.
A MASTER can control many databases.
A client process may only access one MASTER.
A MASTER can be addressed by many client processes.

Simultaneous read access

While a database is being accessed through MASTER, only the MASTER clients can update the database. However, the non-concurrent products can read the database. In order to provide a consistent image for any independent read-only processes, MASTER does not update the database directly. It leaves all of the index blocks and data blocks that comprise the original database strictly alone. It creates a new master index block in memory and then creates new index or data blocks whenever it has to re-write a block to disk.

The database updates are written at the end of the database file and are referred to as the Difference File.

Users accessing the database through MASTER, see the current database, including the most up to date modifications.

Users accessing the system for read only through single-user products see the database as it was when the difference file was last copied. This view is frozen at the point that the retrieval process starts reading the database. Thus, some users can do retrievals on a stable database, while others can update the database without worrying about leaving a particular record only partially updated or created.

Difference File Copying

Difference File Copying means that the database is brought up to date. The phrase "Difference File Copy" is something of a misnomer since very little copying happens. All of the updated blocks are physically in the database but the Master Index for the database ignores them. A difference file copy is simply the re-writing of the new master index that is a trivial task in terms of the amount of work involved.

A difference file copy only happens when MASTER can get exclusive control of the database. Read access by a non-concurrent product always sees the database as it was when the program started. A Difference File Copy occurs:

When MASTER is shutdown
When the last concurrent user closes a database
When told to do the copy
There are two ways to tell MASTER to do a difference file copy:
- Use the COPY DIFFERENCE FILE command from a SIR/XS session that is attached to Master.
- On the machine that is running Master, interrupt Master and go into command mode and use the COPY command.
All databases currently in use by Master are updated. The database updates are now available to stand-alone processes.

The difference file causes the database to grow by the maximum number of updates performed between difference file copies. Any block that is updated is copied to the difference file. If that block is updated again, it is simply rewritten. When the difference file copy is done, the original blocks are no longer required. These are not returned to the operating system but are available for additional updates. If more updates are done, these available blocks are used first. The database thus grows to the point required to hold the maximum number of temporary difference file blocks and no further. The database can be compressed by performing an UNLOAD and RELOAD.

Running Master

The communication process uses TCP/IP protocols and these must be available on your network.

The MST= parameter is the name of the machine where master is running. When Master starts, it tells you the machine and Port (normally :3000). To use a different port, specify the port to use with an MST= parameter on the Master start up.

You can find the machine name from Windows using Control Panel/Network/tcpip/config. The machine name consists of a host and a domain. It makes the start up for clients faster to quote both the host and domain name (DNS).
e.g. Start Master - Get message Master started SirNT:3000
Start a Forms session as a client SirForms.exe MST=SirNT
(If you know the domain name, startup is faster e.g.
SirForms.exe MST=SirNT.sir.com.au)

A connection is established to the specified master process. The client process then specifies a database to access in the normal fashion. MASTER attempts to access that database.

If the user running the client process did not start MASTER (for example, it may be started by the system administrator), the default directories that MASTER is using may differ from the client's. In this case, specify the database prefix in order for MASTER to locate the particular directory that holds the required database. In SIR/XS, this is the prefix on the database connection or on the execution statement, in SirSQL on the CONNECT and in SirFORMS on the DATABASE clause on the FORM statement.

Note: Master allows multiple clients to access the same database and must decide whether a request for access by a client refers to a database that Master is already using. It uses the prefix and the database name to establish this. Master resolves the prefix into a standard form removing any relative references but Master has no way of knowing that different forms of prefixes (e.g. use of different drive letters by different clients) point to the same database. Ensure all client prefix references are identical.

When MASTER is started, it is not attached to any database. MASTER is told which database(s) to use by a client. A single MASTER can access multiple databases. SIR/XS, SirFORMS and SirSQL can access multiple databases through a single MASTER. While a client is using MASTER, all database access is through MASTER.

Command mode

Clients signon and signoff from MASTER as necessary so MASTER is not expecting local input. If you wish to give MASTER a command, press CTRL-Break in the MASTER process window. This stops MASTER responding to any clients and makes it ready to receive commands. To allow MASTER to continue, press Enter. If you leave MASTER in command mode, clients cannot communicate with MASTER.

Shutdown

To shutdown MASTER, go into command mode and enter the command EXIT. The shutdown:

disconnects all users;
updates all attached databases with difference file copies;
closes the attached databases.
stops MASTER

Having a MASTER server that is not shut down has very little overhead. When the last concurrent user of a database signs off, the database is updated with the difference file and is then closed.

Information

Use the LIST command to get certain information about the current session. You can list information about:

CLIENTS - currently connected client processes, ip addresses, time of logon, time of last message and overall number of logical requests made.
DATABASES - currently connected databases.
STATISTICS - Time started, physical messages processed*, logical requests processed*, number of logins, maximum number of users and when that maximum was reached.

The client listing assigns an id to each connection. You can delete client connections with the DELETE id command if necessary if a client process has simply 'gone away' without disconnecting properly.

Please note that while you are using command mode clients cannot use Master.

*While the counts of messages are difficult to relate to specific activity, they can be used to give an overall, general indication of usage or to see that a particular client connection is inactive. In outline, a program issuing a database request must go through a number of logical steps to establish the request, create keys for searches, test success, retrieve data, etc. Where possible these logical requests are combined into single physical messages. However large data records may have to be split across physical messages so the exact relationship between records accessed, physical messages and logical messages is highly dependent on individual circumstances.

Record Locking

Data integrity is ensured through record locking. When updating a record, the lock on the record being updated prevents other users from simultaneously updating the record. Defaults can be used or explicit locks can be specified as required. Locks apply to either whole cases or individual occurrences of a record; locks do not apply to the database as a whole, or to all records of one type.

Writing concurrent programs

When designing systems for a multi-user environment, there are particular facilities concerned with that environment such as locking records. A program that uses these commands for multiple users, can be run in the single user environment without change.

There do not have to be any changes in the source code of a program designed to run in the single user mode to use it in a concurrent environment. If a program was developed for single user mode, it can be run in a multiple user environment and default locks are used.

Lock Types

There are five lock types:

Number	Lock Type	REQUESTS	ALLOWS
2	CONCURRENT READ*	read only access	other readers and writers
3	CONCURRENT WRITE	read and write access	other readers and writers
4	PROTECTED READ	read only access	other readers - no writers
5	PROTECTED WRITE	read and write access	other readers - no writers
1 or 6	EXCLUSIVE**	read and write access	no other readers or writers

* The default in a non-update RETRIEVAL
** the default in a RETRIEVAL UPDATE

When a lock is requested, any current locks on the requested record are scanned for compatibility. For example, if a Concurrent Write lock is requested on a record, the request is granted if the other locks currently granted are Concurrent Read or Concurrent Write. The request is denied if there is a Protected Read, Protected Write, or an Exclusive lock already taken out on the record.

Establishing a Set of Lock Types

Selecting appropriate lock types for an application depends on the type of work to be done.

For users whose jobs entail only reading of data use Protected Read. This allows multiple users to read a record, but prevents other users from simultaneously modifying or updating the record.

If numerous people have to read records simultaneously, but data input is handled by particular individuals, use separate definitions for readers and writers, and then use Concurrent Read locks for the readers and Protected Write locks for the writers.

For maximum control of data input and updating, use Exclusive locks. This allows only one writer and no readers.

Locking can be applied at the case-level or at the record-level. When a case-level lock is required, select a lock type to lock both the CIR and the records for a case. Specify separate lock types for the CIR and records for general access to the case, but a more restricted access to the records.

Locks are set and released by the individual module. Each module has defaults and these can be altered in most cases under program control. For example in FORMS, the LOCK command can be specified for the whole form, when calling a particular screen, and when a lookup is done on a record. An interactive forms user can change lock type on the records they are accessing if the form allows this. Locks can be set and altered in SirFORMS and VisualPQL. Locks in SirSQL cannot be altered.