If your application is session-free, load balancing occurs both at the time of the initial logical connection and for every remote request invoked on that logical connection. For example:
1. When it first connects to an application service, the client asks the NameServer what AppServer broker it should connect to as many times as there are initial connections specified for the binding and creates a physical connection to each broker as the NameServer specifies. The NameServer specifies the brokers for the initial connection request based on the load-balancing settings for the application service. The result of this physical connection process is the connection pool where the number of connections are distributed across the available AppServers approximately according to the configured load-balancing formula.
2. When it invokes a remote procedure request to a connected session-free application service, the client asks the NameServer what broker to use for the remote request. The NameServer returns the broker to use according to the configured load-balancing formula. If the client already has a physical connection available to the broker the NameServer specifies, the client uses that connection to run the request. If the client has no available connection to that broker, the client creates another connection to execute the request, up to the maximum number of physical connections specified for the binding. If creating a connection will exceed this connection maximum, the request is queued for the next available connection on any AppServer broker in the connection pool. If creating such a connection fails (because the broker is unavailable), OpenEdge raises a run-time error on that request.
So, for a session-free application service, load balancing is determined with finer granularity than for a session-managed application service.
