CODEWITHSUNDEEP
sessiontomcatservletscluster-computing
Andy Nuss
Andy Nuss

Reputation: 745

conditional tomcat sticky session (clustering)

I have a web application that does most of its logged in user dependent actions based on a persistent cookie that maps to a database record such that each ajax POST does not need or want a tomcat session.

In a very small number of ajax requests, I have a small amount of servlet session data to save for the logged in user, and I want the session to persist for a very long time (as long as he has the browser open), even if there is a long period of inactivity.

Now, my understanding is that there are sticky sessions or replicated sessions for a tomcat cluster, your choice. In most cases, I would want my load balancer to send the traffic to the least loaded tomcat instance, and the servlet never gets or creates a session. In a very few cases, I need a session and access to the small amount of session data.

Also, I am using apache mod-proxy. Does this constrain the choice?

If I were to choose a sticky session load balancing, then the vast majority of my ajax requests that don't need to be sticky would go to the same tomcat server anyway. Yet some have said that sticky sessions give better performance if you are not worried about failover.

Can someone tell me what the right choice is in my case?

One idea that I had was in that whenever I create a session in tomcat, I also create a MYSESSIONID cookie for just a particular servlet (path) set to the same value as the tomcat sessionid. Then, in all of my very few servlet requests that require access to the session data, I go thru this one routing servlet, and the load balancer can create a sticky session tied to MYSESSIONID cookie. Is this a good solution?

Andy

Upvotes: 0

Views: 916

Answers (1)

JB Nizet
JB Nizet

Reputation: 691635

A session is global to a web app. It isn't tied to a particular servlet in the webapp. Your routing servlet doesn't make much sense.

If you're not worried about failover, then sticky sessions are easier. If you need clustering, this probably means that you have an awful lot of concurrent users. So, in average, the load should be similar on all the servers anyway.

On the other hand, if you have very few data in the session, and your application modifies it rarely, replicating the session should not cost much. You would have failover as an added advantage, and the load balancer could use a pure round-robin algorithm, making sure that each server gets the same number of requests as the other ones.

Upvotes: 0

Related Questions