-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Neven,
On 1/28/14, 8:59 PM, Neven Cvetkovic wrote: > Ultimately, session stickiness works great to handle load > balancing (workload management), but it is not enough for session > failover. Correct: session stickiness just avoids the problem of session fail-over. If you want "proper" session fail-over, you'll need clustering (in some form... Tomcat's clustering isn't the only game in town of course). > In the unlikely event that the serving tomcat instance dies, the > user will be sent over to the other tomcat instance (that doesn't > know anything about you, i.e. doesn't have your session data), and > will probably need to login again. Correct. > Now, as Chris pointed out - it would be great to design your app > that it saves the intermediate work to a database or some secondary > store that can be retrieved upon login again. Think "shopping > cart", you are shopping around, the instance goes down, you need to > login again, and a nice application would persist shopping cart for > you, not so nice application would not, so when logged in again - > the shopping cart would be available or not :) Exactly. Our strategy - for those interested - is to include enough information in each request / form to allow users whose work is interrupted by a login to resume their workflow (in progress) after an interrupted session. This has the added benefit of allowing users to go get a cup of coffee, have their session expire, and pick-up where they left-off after a quick re-login. > Now, if your end users can live with that scenario - that's great - > no need for session replication, clustering your instances, > network chatter, etc... It definitely simplifies the configuration > and setup. If a re-login meant starting-over at a user's "home page" and having to re-start various workflows, it would be much more important for sessions not to fail, and clustering would be more attractive. Clustering is (from my outside perspective) fraught with performance and stability issues -- not because the code is bad, but because the entire strategy is resource-consuming and fragile somewhat by design. > However, if your end users (i.e. your Service-Level-Agreement / > SLA) do require a proper session failover, you will need some sort > of session replication to successfully implement that feature. > That's not trivial and depends on the appserver (e.g. Tomcat, > JBoss, WebSphere, Weblogic). Session replication is not part of the > official JEE/Servlet spec, but most modern and serious appservers > would provide some way of replicating sessions and clustering > appserver instances. On a side-note, one of the things I'm most-often asked is if a new login from a "second" (or third, etc.) client can immediately-expire any pre-existing sessions from the same user. This is a pain in the neck that I haven't put much thought into, yet. With multiple back-end servers, it basically means that you need to re-authenticate the validity of a session with a central authority on every request. *sigh* > Now, if you could make you application stateless - you could > possibly turn off the sticky sessions. Makes things very easy to > scale! +1000 > > :)) > >> the only time I really need failover is when I 'might' want to >> update the app's software. the app is quite stable now and not >> many software changes right now, so again, there's not much of a >> need for failover. :) There's additional difficulty, here, especially if your application changes radically: if you change the behavior of the web application so much that two versions can't reasonably run next to each other simultaneously, you'll require downtime. We do this to ourselves at $work all the time by making structural changes to our database that basically make it impossible to run version X and X+1 simultaneously. The obvious approach is to much more carefully make changes, spread the affects over more than a single release, etc. but it turns out that 30 minutes of downtime once per quarter for new releases just isn't that big of a deal for us, so we don't bother to spend all those additional resources to make it happen. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS6R0kAAoJEBzwKT+lPKRYKmQP/RWhnKWRYV0gksTSDdzQyf9f t80TJMTk1F5sHlDBKjAxaG9EIVf8loJ7LILaKcwm1jHLjfn2CrQJKr7h0wRwJPH1 NbFaRUv4Y5KGa63ZEQQtlYYRmZxVPfLL2V1jA/g0PgOHvTWV5xoUtARryqFSZcQG +kqOLeujPcNDtepqFNNRB0JGx0H7fNwEW/sobrIbramRieo834BsOkF7qkpEmCG1 pl2cTbTtk8O9oxz9FXXYHf5x6luXx1j2GY9Htk/ZErKveUU24oYPi99zkSfb+EeM b7ufb6N2EfLs88mTOgRtbH+9BYJUcJ5s9i28oeMQ7bhq3a1asJz6gWllwfJSXAvJ d4qu8NUNRe4C/CQ7XQlUhxfGdeDZZkm4q3iLLQomFWD1NdrZMawbZyRw5+BMZhgQ rD0mT6vPawNUbQM4RGF0vDVK11Yuztgd0RAO8g7GGVO63qrCM1/olSo5OZPO2fbm GICNYL0SbU3jQ8C6rud26uB1NCMEjE4i4LP1nRJ3iOa50A0wJcQayPJ/vf4ie21z 9ywlV1Y4QkHqUT5gTN95XnKoecO4vKKHot/s8LTsClXgU1jygL0+EfvIqWnOIYoo e6K3IRA878B7rSKtyV2c/3CJi50KRq1LvYcLsoMKzaMIeFSOZfpcYWzD45G9/Yyk BqgeQJd/tV6VMyOErKlK =JlWo -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
