-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lb,
lightbulb432 wrote: > Let me see if I have my options straight - stateless app tier and no session > affinity, or stateful app tier (i.e. HttpSessions) with session affinity? That sounds about right. Don't forget that you can't be stateless if you need logins of some type (unless you use BASIC auth, which looks ugly from a user point of view). > The former allows you to forward the next request to any available web > server because of no session affinity and to have failure without relogin, > both of which seem like huge pluses. However, the downside is having to > maintain that state elsewhere - either in the database (which as you pointed > out is messy) or being sent back and forth to the client. Which of these > options seems better at first glance to you? I'm not convinced you can reasonably do authenticated transactions (using Tomcat's auth) without stateful connections. You can hack around with storing login cookies or doing your own auth management, but I like the simplicity of using J2EE auth. > If I were to go with a stateful app tier (i.e. HttpSession with session > affinity but no session replication), what's the overhead of session > affinity? Pretty much nothing, unless you get lots of people who login and then walk away from their computers, and for some reason all of the walk-aways get assigned to one server, while all the other (active) users end up on another server. Then, you'd have one server with lots of load and one that's basically idle. This is unlikely, though. > I realize that if there's no requirement for failure without > relogin then this option could be better, but from a pure performance > perspective, how big is the overhead caused by session affinity having to be > resolved upon every request? I would assert that it's immeasurably small. It takes more time to parse the context name and do JkMount evaluation than it does to figure out which server to choose from the cluster. > Is there ever a benefit, from a Tomcat perspective or other, to having a > stateless app tier but WITH session affinity, or would that be completely > useless? It sounds useless, but I'm sure there's a reason to do it. I guess you could have an app that is strictly stateless, but can benefit from a session nonetheless. For instance, let's say you have a search app. You might want to cache the results of the search in the session for paging purposes to improve performance. If you get bounced to another server, you can always reconstruct the search from the information in the request instead of using a cached copy, so it's strictly stateless, but you also get a benefit from some kind of state. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0z309CaO5/Lv0PARAieCAKCtEXwBpWTSCxMX5I9G1LoHUhJlWQCfdf1J B3NgNH++vwleqVFfC0+R9/Q= =MnEh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
