The FairCom Server provides a flexible, high performance implementation of the FairCom DB index and data file functions for multi-tasking and network systems. The clean separation between the Server and the implementation-dependent message handling allows implementation of the FairCom Server in different environments by changing only the message routines in the client-side library.
FairCom Servers are licensed separately for development and production. The developer license activates the FairCom Server with eight connections for development purposes only. When the application is fully developed, tested, and ready for distribution into commercial service, a production FairCom Server license is required for each Server host machine, typically one per network.
The FairCom Server is licensed on a concurrent connection basis. Each connection to the FairCom Server counts against the total until the connection is closed. A client establishes a connection with every successful FairCom DB initialization call, with multi-threaded application potentially establishing many connections.
Additional information is located in the FairCom Server Administrator’s Guide, including installation information.
The client/server model offers the following features:
Reduced disk I/O: In the non-server mode, applications cannot perform local file buffering, or applications would have inconsistent views of the files. Therefore, all disk I/O is forced to and from the disk. In the Server mode, the FairCom Server performs all disk I/O allowing user controllable caching.
Reduce traffic on Networks: In network systems the FairCom Server reduces the amount of network message traffic, provided the node running the FairCom Server is also the node where the FairCom DB files are stored. In the non-server mode, all disk I/O must be sent over the network. In Server mode, only the application request and the Server response go over the network.
Transaction Processing: A sophisticated set of functions provides industrial quality on-line transaction processing, including full commit and rollback, savepoints, and complete logging. Transaction processing is covered in more detail in “Data Integrity”.
File mirroring: Selected files are mirrored to separate physical devices or partitions, offering extreme data protection. See “Data Integrity”.
On-line backups: On line backups make it easier for administrators to perform regular file backups. See the FairCom Server Administrator’s Guide.
Multi-threading: All FairCom Servers are multi-threaded, regardless of whether the operating system offers multi-threaded functionality. On platforms where efficient multi-threading is available FairCom Server uses O/S provided threading calls. On other platforms that don’t offer threading the FairCom Server uses a low-level, rapid context switching threading kernel written by FairCom.
The multi-threaded design of the client/server model, the data/index caching and the reduced network traffic all assist in minimizing the load on the network as more users are added. The degradation in user response times as more users are added to the FairCom Server is much less than with other multi-user models.
Relaxed File Numbering: On systems that do not support record write locks, and for which a FairCom Server is NOT used, FairCom DB can use a dummy file to permit exclusive locks to operate as write locks. However, this requires the same file to be assigned the same file number by different applications, and different files to be assigned different file numbers. The FairCom Server permits different applications to assign the same file different file numbers, or to assign different files the same file number without causing problems.
No Operating System Lock Limits: Many operating systems limit the number of total locks or locks per application. The FairCom Server avoids this restriction by maintaining internal lock tables and minimizing system-level locks.
The FairCom Server executes all FairCom DB functions. When you link your application to a FairCom DB application library set up for the FairCom Server, your application becomes bound with the required system dependent message handling functions. The resulting executable module can only run on a system designed to support the message handling routines included in the link step. This executable module cannot run as a stand-alone, single-user application, unless it is specifically built with local library support as discussed later in this chapter.
