Take another look at the hardware load balancer documentation for sticky session support, they might of called it something else. Google searching for your LB vendor name and sticky sessions, might help you find it.
Some vendors use the terms "session persistence" or "persistent sessions".
Based on the replies, further investigation on the load balancers shows that it does support multiple methods of persistence.
However, we have a custom written sso process that brings up another problem. While persistence would direct the user to the same server every time, it doesn't mean that the sso module will hit the same server when it log into the application. Let me provide more details. We have 2 applications (app1 and app2) running on 2 servers (server1 and server2) behind a load balancer.
Now, when a user requests the login page, the load balancer will direct them to app1 on either server1 or server2. When the user has completed filling out the login form and hits submit, they could then go to app1 on either server1 or server2. "Sticky Sessions" would make sure that they got back to the same server of their initial request.
Now, app1, running on either server, issues a login request to app2 on either server1 or server2. Upon successful login, app1 redirects the user to app2. The redirect will automatically tell the browser to request app2 and the load balancer will send that request to either server1 or server2. Again, with sticky sessions, the user will go the the same server of their original request. But, the login request is being initiated by a different "user" and might go to a different app2 server. When the redirect request comes back in from the user, they may or may not be sent to the same app2 server that app1 logged them into, and since the cluster hasn't sync'd, they will either get the welcome page (or bookmarked page) if the login server was the same as the sticky server, or they will get the login page from app1.
So, how can this dilemia be resolved?