Take the 2-minute tour ×

I am working on a number of web projects for a firm. Most of the projects are about one or two pages of input and then doing a save to a MySQL database. My system administrators are pushing to try to get session replication working in JBoss, but I don't really see any need for it and all of its overhead. We need load balancing and clustering so if the server does go down we can move the new requests to the backup server, but I am not to big in session replication.

This is very low volume projects. In my eyes, what are the odds of a user being in the project as the server goes down on the one or two pages? I am trying to convince the system administrators that session replication is an unnecessary complication in this instance.

In my situation, should I be using session replication? If not, what are the best reasons to not use it so I can convince the system administrators?

share|improve this question

migrated from ux.stackexchange.com Dec 5 '12 at 17:22


Are you saving any data in the session? What is the expected user experience when the system fails over and a user is on page 2 of 3 in a workflow? How much time/money would be lost in the event that data is lost when a cluster fails over? Do you do a rolling deployment (turn off one server, update it, turn it on, turn off the other server update it, turn it on) for reduced outage? How often had you had a machine in the cluster fail over? –  MichaelT Dec 5 '12 at 18:46
I am at a new project at a new firms and I very that session replication is over kill. The projects are very low vol... and its not like its a trading system. Just trying to show them that the overhead of session replication is a big price for us –  techsjs2012 Dec 5 '12 at 18:56
Depending on the size of data, wouldn't it make sense to just use cookies for session data (or hidden values in html forms). Then you wouldn't have to worry about what server you are talking to. –  ssgriffonuser Dec 5 '12 at 23:37
@ssgriffonuser: Using cokies for session data adds a cost to every server request. The whole point of a session is to map a key, usually stored into a small cookie, to a larger chunk of data. Of course, there are also security concerns. Once the user can access their session, their session is now user input, which must be verified (the session data is used for anything beyond client-side functionality like display settings). Further, there's still the question of tracking the user's login status, assuming the site has logins. –  Brian Dec 5 '12 at 23:49
@Brian: I agree there are down sides to storing session data on the client side, whether it is a cookie or embedded in the web page. But I disagree that "the whole point of a session is to map a key, usually stored into a small cookie, to a larger chunk of data". The point of a session is to persist data across multiple requests. There are multiple ways of doing that. If the data is stored on the client side (perhaps encrypted for security reasons) then you no longer need to worry about session replication. –  ssgriffonuser Dec 6 '12 at 0:43
add comment

1 Answer

We typically use a pattern, where a session's content is split between what is only needed on this server (often, but not allways an empty subset)and what has to persist between servers. The latter part is then written to a temp store (mostly memcached) on session save, recalled on session load.

This allows not only passing round between servers, but also between different platforms: Think of a Webapp that is gradually moved from e.g. PHP to JBoss.

In my experience, the memcached overhead is far lower than the session replication overhead, especially as the number of servers grows.

share|improve this answer
add comment

Your Answer


