3 ms·

Isn't an external session store practically mandatory regardless of your backend? I'm no fan of Node, but even if you have $100k machine running the JVM with a

Isn't an external session store practically mandatory regardless of your backend? I'm no fan of Node, but even if you have $100k machine running the JVM with a thousand threads you will (if successful) eventually need a second machine, and a third, etc. Not to mention persistence (what if you need to restart the app server?). Sessions belong in a database of some kind unless you can get away with signed cookies.

mahmud 15y ago
no it's not mandatory. We use Play and it's super stateless. nothing more than client side cookies. forced us into scalable, share nothing design. love it! http://playframework.org/ http://playframework.org/ for java and scala
- SkyMarshal 15y ago
  The Lift web framework does this too, as does Apple's Web Objects. David Pollack, creator of Lift, wrote a good explanation of the benefits on Quora, will post it shortly.
  - bronson 15y ago
    EDIT: Strata ships with cookie-based sessions but it's pretty easy to write your own storage middleware: var app = strata.redisSession(app, options); After seeing how awesome the default cookie-based sessions are in Rails, I'm not sure I'd ever care to go back. Maybe for a high security banking app where breaking the cookie encryption could have catastrophic, permanent repercussions? Short of that, load balancing shared-nothing cookie-based sessions is a joy. Gotta agree with the Lift guys there.
  - SkyMarshal 15y ago
    Can't edit my post, so here's David's case (in comments under Jackson Davis's answer): http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-app-in-Scala-using-Lift http://www.quora.com/What-are-the-advantages-and-disadvantag... "In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security. Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..." So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550.. http://blog.harryh.org/post/7550... So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.) Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
    - bretthoerner 15y ago
      I'm confused, are they saying Twitter etc have scaling problems because of sessions? Sessions are just about the easiest thing to scale. What am I missing here?
- hello_moto 15y ago
  I assume play does not use DB pooling if it is a pure 100% share-nothing design?
olegp 15y ago
Java web app containers support distributed session stores.

mahmud 15y ago

no it's not mandatory. We use Play and it's super stateless. nothing more than client side cookies. forced us into scalable, share nothing design. love it! http://playframework.org/ http://playframework.org/ for java and scala

SkyMarshal 15y ago
The Lift web framework does this too, as does Apple's Web Objects. David Pollack, creator of Lift, wrote a good explanation of the benefits on Quora, will post it shortly.
- bronson 15y ago
  EDIT: Strata ships with cookie-based sessions but it's pretty easy to write your own storage middleware: var app = strata.redisSession(app, options); After seeing how awesome the default cookie-based sessions are in Rails, I'm not sure I'd ever care to go back. Maybe for a high security banking app where breaking the cookie encryption could have catastrophic, permanent repercussions? Short of that, load balancing shared-nothing cookie-based sessions is a joy. Gotta agree with the Lift guys there.
- SkyMarshal 15y ago
  Can't edit my post, so here's David's case (in comments under Jackson Davis's answer): http://www.quora.com/What-are-the-advantages-and-disadvantages-of-writing-a-web-app-in-Scala-using-Lift http://www.quora.com/What-are-the-advantages-and-disadvantag... "In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security. Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..." So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550.. http://blog.harryh.org/post/7550... So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.) Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
  - bretthoerner 15y ago
    I'm confused, are they saying Twitter etc have scaling problems because of sessions? Sessions are just about the easiest thing to scale. What am I missing here?
hello_moto 15y ago
I assume play does not use DB pooling if it is a pure 100% share-nothing design?

olegp 15y ago

Java web app containers support distributed session stores.