Data may not be as predictable in production as you saw it in development, which may translate into the size of your session objects. The session objects are objects that contain data you use to store state (save the user session) on the server. You will most likely keep the username and password, some preferences, and, depending on the requirement, a whole range of other data sets. Session replication is when you take the session or state of a user on Server A and make a copy of that session for failover purpose. The idea is that if a user is logged on to a machine and it goes down, he can resume work on Server B without having to re-authenticate or lose the non-transient data before it is persisted to disk or database. When you move the application from a development environment, which has a small set of test data, into production, where the data may be ten times the size of the test, you may run into problems. The way the application is used may be different when you use it in production. Production may have sessions that are several megabytes in size. The challenge to understand is how your code is handling these large sets of data coming back from database, or downstream system. Let’s say you do a search and bring back a list of six hundred records. If persistence is on, this object is stored in session, and then the application server will replicate the data to another node in case of failure. Now, six hundred records may sound like a lot, but the process of serializing and sending them across to another node in the cluster does take some time and resources. You need to be aware of the data that is transient and can be thrown away, as well as what you need to persist (save) in the near and long term.
Comments