Share session information
3.2 Sharing Session Information Our first concern is that in the event one instance goes down, their session would be lost and they would need to recreate any work they had performed on the now down server (authentication, any workflow, etc.) In our banking example, perhaps it is as simple as authentication and creating a ‘stock watch’ list. To address this issue, we flag our application as distributable. This is as simple as adding the tag to our application web.xml such as the following: Illustration 1: Adding distributable tag to web.xml Where we are now – we have redundancy at the OS and hardware level by having multiple instances at the HTTPD and EAP layers (HA disc provided by RHEL). We now just added session replication to our web application. This makes it so that if one application server goes down, a user will continue on without interruption to their workflow. This resiliency is free in the comparison to our previous additions which required additional hardware. This will add network traffic though. Please look at LINK TO TUNING DOC our tuning whitepaper for considerations that this may have on performance. We now have our application replication setup. Our application deals with market data. With market data, some information has a high rate of change and some less frequently. When an application server recovers, if there isn’t a way for it to catch up data state, we could be exposing our customers to unnecessary risk. Lets now consider our cache and how we could persist it for a quicker application state recovery