3

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?

5
  • 4
    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?
    – user40980
    Commented Dec 5, 2012 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
    Commented Dec 5, 2012 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
    Commented Dec 5, 2012 at 23:37
  • 1
    @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
    Commented Dec 5, 2012 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
    Commented Dec 6, 2012 at 0:43

1 Answer 1

Reset to default
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.