What you are talking about is a pretty massive infrastructure needed by only a handful of large companies (i.e. ebay, google, etc); for medium-large companies with traffic up to say 1-10 mil pageviews/day , some degree of server-stickiness with 80 odd servers is probably not the worst thing in the world.

Second item of study reinforces what Google says. Read ebay’s write-up on scalability (google: ebay scalability). Ebay architecture has evolved through the school of hard-knocks. One of those hard-knocks was servlet sessions. Ebay was simply being crushed in 2002. Now they serve over two BILLION pages views PER DAY. Something according to them (don’t take my word for it) they could never have done if they had persisted with their server-side session-based architecture.

This is “Web 2.0″ and beyond kids. Java can scale massively; better despite any language debate than any modern language thanks to the JIT. But a well architected Ruby site (for christ sake!) can beat a poorly architected Java one. Let go of your “servlet sessions” and 1990’s server architecture.

Memcache, combined properly with client-homed sessions and “stateless” servers is the way of the future. Computing clouds, instant and seamless fail-over are the goal here. “Session” or “server” affinity are be a thing of the past. Login to ebay and look at your cookies — nearing 2 dozen — that’s ALL your state. Do you think any two of your requests go to the same server at ebay? You would be wrong.

I’ve seen a PHP dev coding Java (apparently for 2 years already) make their doGet and doPost methods synchronized in a Servlet. It’s not that PHP is simpler, just Java has more intricacies (like threads) that monkey devs don’t “understand”.

One other point on Java and corporates is: most go with J2EE sites in the most stupid ways imaginable. For example:

Data Object -> Data Store EJB -> JDBC Driver -> Database

See the additional network round-trip in there? That structure is the norm with Java monkeys, and it’s just plain idiotic. I have a very low opinion of most J2EE developers (their are a few exceptions), since most seem to be covering their own incompetence with a framework.

PHP / Memcached sites are light years ahead of Java sites in terms of speed. Look at any typical Java based banking site…my god are they slow.

As for the cookie problem, there is a solution in the servlet api: HttpServletResponse.encodeURL. This method will automatically detect if the user doesn’t have cookies, and encode URL’s with the session ID if they don’t. It’s considered bad practice when it comes to SEO, however the crawlers all seem to support cookies as well (so they will only see it on one page).

To fix the URL’s in JSP pages, you can use the JSTL tag <c:url> to both produce an absolute path to a resource, and encode the session ID if required.

I’m curious to know how you would go about tracking a customer for a whole year with memcached, considering it’s likely to throw the session away long before that time is reached, and without cookies or some form of URL encoding you can’t tell one user from the next.

You could crank the session timeout as high as you like. Inactive sessions are serialized to disk (some servlet containers also do this between restarts), and so their timeout is guaranteed rather than based on load.

As for the load balancer concerns, that is a good idea. And we are using it, already.

P.S. You could be more polite to people who posts here. Just a suggestion.

If you’re concerned with session migration, have your load balancer run sticky sessions, which will provide a much faster solution than memcached, since the users sessions will never need to move across the network (we run this way on 80 machines with no problems).

If you are going to use memcached with Java, use it for a cache. Tracking sessions with memcached in Java is a really bad idea (not to mention a terrible waste of resources).