Session load balancing maintains the integrity of state and session information for AppLogic objects that do not distribute session information. This is done by limiting processing of requests for such objects to the Java Server/C++ Server process where the initial session was created.
Session information that cannot be distributed is lost if requests within the same session are processed by more than one Netscape Application Server or Java Server/C++ Server process. AppLogic objects marked for sticky load balancing are, therefore, processed on the same process, thereby eliminating the loss of session information. The initial request can be processed by any Netscape Application Server that stores that AppLogic object, but once the first sticky object is invoked, all subsequent sticky request are processed on the same Netscape Application Server process.
When to Use Sticky Load Balancing
Sticky load balancing is necessary for AppLogic objects that have interdependencies but are running in a distributed environment. Such AppLogic objects would typically have the following characteristics:
For example, a heavily used, pre-existing application is ported to run on the Netscape Application Server. Because the application is heavily used, it is distributed across several Netscape Application Servers to increase availability. When a user makes a request that invokes a Sticky AppLogic object, the load balancing service determines which Netscape Application Server should handle that request. Once that server is chosen, all subsequent requests that use Sticky AppLogic objects are handled by that server. If that server becomes burdened with many users' requests, the load balancer forwards new requests to another Netscape Application Server and that server processes all new session requests. This maintains an effective degree of load balancing.
For information about setting session load balancing for AppLogic objects, see "Enabling Session (Sticky) Load Balancing."
|
Previous
