The question of using Oracle WebLogic with AWS Auto Scaling and propagation of session state is often asked. Before getting into the details, let's look at the two ways of handling session state at the server layer (using cookies in the browser can be used as well):
1. Session stickiness : session data issue is to send all requests in a user session consistently to the same backend server.
2. Session in database : Another solution is to keep the per-session data in a database. Of course, AWS ElastiCache, SimpleDB or DynamoDB, or RDS.
If the session is stored in a database, nothing needs to be done when using Auto Scaling with WebLogic; for obvious reasons.
When sticky sessions is used, nothing needs to be done, but the reason is not so obvious so let's discuss it.
1. Session stickiness : session data issue is to send all requests in a user session consistently to the same backend server.
2. Session in database : Another solution is to keep the per-session data in a database. Of course, AWS ElastiCache, SimpleDB or DynamoDB, or RDS.
If the session is stored in a database, nothing needs to be done when using Auto Scaling with WebLogic; for obvious reasons.
When sticky sessions is used, nothing needs to be done, but the reason is not so obvious so let's discuss it.
When a request comes into a WebLogic cluster via a load balancer (AWS ELB for example) or through Apache (mod_proxy_balancer plug in) the first time, WebLogic creates an HTTP session on the primary node and also puts session state on a backup node. (You can provide guidance/control where to put the failure/backup). If the server goes down that contains the primary WebLogic node, the new primary node will know where the backup session is stored and the session state will automatically get replicated to the new node. So when AWS Auto Scaling is used there is nothing that needs to be done from an AWS perspective.
