Setting up a Transaction Server to Publish a Database

If a PMOD installation has a JDBC database running, it can make the data available for other PMOD installations. To this end a server program - the Transaction Server (TS) - must be started to run in the background and wait for database access requests.

In PMOD multiple TSs can be started automatically. Therefore memory usage for multiple TS is optimized while providing a better management of the TSs.

Transaction Server Configuration

The transaction server requires several configuration items, which are available on the DATABASE panel. Perform the following steps to define the transaction server which is started automatically with PMOD.

1. Switch the radio button from Use JDBC connection to Use Transaction Server.

1. Configure the properties of the transaction server. The Secure box is for enabling secure communication. This mode should be used if the communication is not confined within the institution. Otherwise it will slow down the communication speed unnecessarily.
2. An important property is the IP Port for the communication. It must be a unique number not used by any other transaction server or other process. In the example above is 5200.
3. Another important property is the IP address. It must contain the address of the host in which the servers are running, so typically the system on which the configuration is performed. For this system the HOST button is enabled and the host system is "localhost". In alternative, the IP address can be obtained by activating the Set Local Host button.
4. Check the box Start automatically such that the transaction server is started simultaneously with PMOD. To use a Starting Script as explained below and check the Standalone box.

Starting a Transaction Server

The PMOD transaction server is a background process. It can be started in one of the following ways:

1. Automatically: If Start automatically has been configured in the DATABASE configuration page, the transaction server is started as soon as PMOD is started.
2. By running a command script: A script for starting a Transaction Server is specific for the operating system platform. A start script RunDbSvr with the default configuration is created at installation time in the Start directory. Transaction server scripts with a different configuration can easily be generated on the DATABASE configuration pane as described below. As an example, the RunDbSvr script for Windows looks as follows:
   C:
cd "C:\Pmod3.9
.\java\jre\bin\java -Xmx2G -jar pmtsvr.jar 5100 JAVA_DBS ./DATABASES/DbSvr -noLS
pause

Note tat there is dedicated server administration tool which can be used for monitoring, starting and stopping the transaction servers for which starting scripts have been created.

Transaction Server Scripts

The Save Starting Script button is a facility for generating scripts according to the configured transaction server properties. It becomes active when the Start automatically radio button is disabled and Standalone option is enabled. The script is dependent on the operating system. The example below is the result for a Windows system.

The -noLS text indicates that the TS is not used as license server.

The License Server box can be checked if the server is at the same time managing a network license. In this case the -noLS flag will disappear.

The Verbose commands box can be checked to enable verbose output. In this case a -d argument will appear. It is only recommended for debugging purposes, because it will slow communication down.

The Redirect output box can be enabled to redirect the output to a log file. In this case a -o argument will appear.

The Yes button saves the operating-system specific script illustrated in the commands area to the Pmod3.9/Start directory using the specified Name.

An additional command line flag which can be added to the script in an editor is -optimize. If it is present, the database table indexes will be optimized before the database gets accessible. Note that this may take notable time for large databases, but it can dramatically improve speed for aging, large databases. To keep the database fast and safe, a TS started with the -optimize flag will backup the database tables to data/DB_Backup/ every Sunday night at 1am and then optimize the indexes.

Another startup option is -upgrade. With this option a backup of the database is copied to data/DB_Backup/upgrade/, then the database upgrade scripts are executed, a table optimization performed as with -optimize, and finally the Transaction Server started.

Transaction Server Status Information

All automatically started TSs are available for management from the PMOD ToolBox. The TS management is opened by activating the button in the ToolBox:

The current status is displayed in the State column. The status of a TS can be easily modified: initially the TS has to be selected in the Server list and then, depending on the status, the Start selected server(s) or Stop selected server(s) button need to be activated.

When the color of the button changes to blue, a transaction server request is being served. The color changes back after all communications have completed.

PMOD Status

In case of problems with the TS status the PMOD status button in the ToolBox shows a red bullet.

Dedicated Machine for Databases and Transaction Servers

Note that transaction servers can be started and operated without consuming a PMOD license. This allows moving them to a server machine that is continuously operating and has fast disks. On this server machine perform a standard PMOD installation, plug the USB license protection key in, and use the Config facility for the database configuration and transaction server script generation. Then start each of the scripts in a separate command window. In the case of a standalone license, the USB key can now be moved to the computer, where the actual data processing is performed. In the case of a network license the USB key should remain, as it is used for license serving.

It is easy for Mac OSX and Linux to start programs like the transaction servers at system boot time and run them in the background. On Windows, this is not possible with normal programs. Rather, a command window is required which needs to stay open for the whole program duration, which is not convenient for shared server systems. A workaround is to purchase a third-party solution which wraps the transaction servers into service processes, such as the AlwaysUp solution.

Depending on the network and server performance the speed of the load/save operations via a transaction server may be slower than with local loading/saving. The benefit, however, is the global availability and centralized maintenance of the data.

CAUTION: Note that the proper interaction between the transaction server and clients requires that all systems run the same PMOD version.