Cross-port affinity | Active-cookie affinity

Load Balancer: Passive cookie affinity

Passive cookie affinity is based on the content of cookies (name/value) generated by the HTTP server or by the application server. You must specify a cookie name to be monitored by Load Balancer in order to distinguish which server the request is to be sent to.

If the cookie value in the client request is not found or does not match any of the cookie values of the servers, the most appropriate server at that moment will be chosen by Load Balancer.

This feature requires that CBR forwarding is used and works only on HTTP ports, not on HTTPS ports, because Dispatcher cannot decrypt SSL content. For content-based routing of HTTPS traffic you would need to use the Load Balancer CBR component in conjunction with IBM WebSphere Edge Components Caching Proxy. This configuration is beyond the scope of this book. Refer to Concepts, Planning, and Installation for Edge Components Version 6.0, GC31-6855, for more information.

Although looking at cookies could help to overcome the drawbacks of source IP affinity, there are reasons why this type of affinity does not work well with WebSphere Commerce generated cookies:

• The cookies WC_USERACTIVITY and WC_AUTHENTICATION are only generated when a generic user logs in or adds an item to the shopping cart.

  From these points, the users are not generic users anymore. They are registered or guest users identified by a user ID. WC_USERACTIVITY and WC_AUTHENTICATION cookies carry the user ID as part of their names, not values. Load Balancer cannot be configured to look for cookies with names consisting of a static and a dynamic part.

• The cookie JSESSIONID identifies the HTTP session and would be a good candidate for routing requests to the same Web server for a user session.

  This cookie's name is static, so Load Balancer can identify it in HTTP requests. But Load Balancer does not keep track of the Web server used for the first request made with a new cookie value (it does not hold the cookie value). Rather than doing that, it requires that each server configured for a port is assigned a fixed value, which is compared to the cookie value at every request. If the server value is contained in the cookie value, the server is chosen to handle the request. JSESSIONID carries as part of its value the clone ID of the application server that handled the first request of the session, so JSESSIONID could only be used to link Web servers and application servers, which we do not recommend for WebSphere Commerce.