Shared and Exclusive Servers
A Uniface Server can be started as a shared server, which can process requests from multiple clients, or it can be started as an exclusive server, which has a direct connection with the client.
Uniface Servers are usually started by the Uniface Router as required, but they can also be started manually, or using the UROUTMON API. By default, a Uniface Server is started as a shared server, but it can be started as an exclusive server using the /ex switch.
When using TCP, an exclusive server's connection with the client may be inherited from the Uniface Router, or it may have its own listening port. When using TLS, the exclusive server always has its own listening port. For more information, see Logical and Physical Connections and Network Connection Endpoints.
Performance Considerations
Both shared and exclusive Uniface Servers have consequences for performance. Shared servers use resources more efficiently and can handle a greater load, whereas exclusive servers normally provide better performance but use more resources.
Shared servers work best when client requests are short and stateless, because long and stateful transactions lock the Uniface Server and prevent other client requests from being processed. For example. when handling database requests that require large numbers of records to be selected, the specific server is locked for that client for the duration of the selection.
If a component instance is created on a server, any subsequent activation of an operation on that instance must be routed back to that same server. This activate request then has to wait until that server becomes available, which may be some time if a large database request is underway for another client. This can also be the case if another client has also created a component instance.
By default, only one database transaction is
created in a shared server process. This means that if a remote instance of one client performs a
store and commit or a rollback, all
outstanding changes are committed or discarded from remote instances of other clients, and any
incomplete hitlist is truncated. To prevent this, you can set the
Transaction property of the component instance to True. This
causes each client to get its own (encapsulated) transaction within a shared server process.
However, this may cause delays if one client's commit transaction takes a long time, thereby
blocking other clients from committing. For more information, see Transaction.
Tip: Use stateless activate requests whenever possible. Stateful component requests need to go back to the same server. If this happens frequently, contention problems can occur. For more information, see activate.
Exclusive servers, where the client talks directly to the server, normally provide better performance, but require more resources. Using shared servers means all requests to servers are passed through the Uniface Router. This is slower, but because fewer resources are used, overall performance may be better. Re-directing requests from servers to other servers introduces extra steps.
Both shared servers and exclusive servers handle synchronous and asynchronous requests from client processes. However, routing asynchronous requests to a shared server is preferable, because these requests are not performance-sensitive.
Exclusive Servers and Firewalls
The use of exclusive servers has an effect on the use of a firewall.
- When an exclusive server inherits the client connection from the Uniface Router, only the port number used by the Uniface Router needs to be available through the firewall.
- When an exclusive server creates its own listening port, it can use the /gates switch to specify the range of ports that should be used for the exclusive connection, and hence to be made available through the firewall. For more information, see /gates.
- When a NAT (Network Address Translation) firewall is used between the client and the server, use the /hostrc switch with the UST declaration in the Uniface Router’s assignment file to specify that the host name, rather than the IP address, should be used for reconnecting to the client. For more information, see /hostrc.
Exclusive Server Failure Recovery
If an exclusive Uniface Server is killed or crashes, the recovery behavior depends on whether inheritance was used or whether the server has its own listening port.
If the port is inherited, an error is returned when the client executes a subsequent operation. Executing it again starts a new exclusive Uniface Server. It is not possible to reconnect to the same server.
If the server has been configured as a listening exclusive server, it is possible for a client to reconnect to the same server. In this case, the server listens for new client connections for the period of its $NET_TIMEOUT idl setting. For more information, see $NET_TIMEOUT.
A client using an exclusive listening server will always try to reconnect directly to that server. If that server is no longer available, all reconnect attempts will fail. The developer must explicitly code an open or close ProcScript statement to reset the path to its original value. The next operation will then start a new exclusive server. For more information, see open and close.
