Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

How to host AEM applciation with non sticky sessions in WebFarm

Avatar

Level 1

We are currently facing an issue.

1. Presently the site (developed with AEM 6.0) hosted in a webfarm with sticky session configuration done in AWS load balancing.

2.  The client wants to avoid sticky session. now we need to provide solution.

a. how can we host application in webfarm with non sticky sessions?

is there any way to configure AWS load balancing options and configuring AEM (6.0 or 6.1) to keep session on out proc (something like storing on DB) 

thanks in advance. Plesase guide.

~SV

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

it heavily depends on the case you use sticky session. I assume, that you want to store temporary data in the session, which cannot be stored in a cookie. From my point of view you have these options:

  1. Use session replication (in which case you would probably still prefer sticky session, because it eliminates the risk of facing race conditions)
  2. store all temporary data in the JCR and cluster the repository.

In any case you should revisit your design (and the reasons why use http sessions at all), because option 1) will improve your situation not that much, and 2) is a major design change in your deployment architecture.

kind regards,
Jörg

View solution in original post

1 Reply

Avatar

Correct answer by
Employee Advisor

Hi,

it heavily depends on the case you use sticky session. I assume, that you want to store temporary data in the session, which cannot be stored in a cookie. From my point of view you have these options:

  1. Use session replication (in which case you would probably still prefer sticky session, because it eliminates the risk of facing race conditions)
  2. store all temporary data in the JCR and cluster the repository.

In any case you should revisit your design (and the reasons why use http sessions at all), because option 1) will improve your situation not that much, and 2) is a major design change in your deployment architecture.

kind regards,
Jörg