You may have a couple different issues going on here at the same time, but to be clear, if subsequent requests to your load balancer are being handed to different back-end servers, then that is totally a load balancer issue. ColdBox runs on the application server and cannot affect in any way which server the load balancer is going to hand a request off to. At the point that a request has reached Coldbox, the LB has already done its work.
Ask your network tech what the timeout is for server affinity. It is possible they have sticky sessions turned on, but it times out after only a few minutes. Your LB probably has a max session time as well (don’t confuse LB sessions with CF sessions). At my last job, our load balancer appliance would only remember sticky sessions for a maximum of 60 minutes. That meant that people coming back from lunch were likely to get sent to a different server.
Another thing to ask your network tech about is which OSI level your LB is operating at. Layer 4 is pretty basic as it mainly uses IP address to recognize an incoming request. Layer 7 can introspect the HTTP request and use things such as cookie values to recognize the user.
One issue we’ve continually had on my site are people whose IP address changes when they switch from HTTP to HTTPS. A lot of corporate and government firewalls seem to direct secure traffic over a separate WAN IP. This will screw up Layer 4 load balancing every time. The solution we used, was to base login status off of the client scope which is stored in the database. That way, when a user does hit a new server, their browser cookies let them keep their client scope which keeps them logged in. I then re-create anything in session on the fly if it doesn’t exist.
ColdBox Platform Evangelist
Ortus Solutions, Corp