Thanks for your response. So it sounds like session replication is out for sure - you confirmed my initial feelings about it.
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? 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? 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? 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? 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? Christopher Schultz-2 wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lightbulb, > > lightbulb432 wrote: >> How are you designing your current applications, and what >> implications has the choice that you might not have expected - would >> you do anything differently if you could? > > (For the record, I am not using session replication.) > > It all comes down to what is most important for your application. > > If it is unacceptable to have users re-login if the server to which > their session is tied (session affinity: no replication), then session > replication is one of your only options. > > If it's okay to have users re-login when they switch servers due to > failover, I'd highly recommend it since session replication is pretty > heavy in terms of network use. Why waste all that time passing session > information around? > >> I ask because I'm still unsure about whether to decrease memory usage >> by increasing database usage (or bandwidth usage if sending state >> back to the client) by going stateless at the application tier. > > You don't necessarily have to go stateless. Using a session is fins as > long as it's okay for users to re-login when they switch servers. > >> Stateless >> >> Are there any people using stateless application tiers with >> transactions that are inherently stateful, such as wizard-type >> screens or other business processes or workflows? How'd that turn >> out? > > I have some flows that are sort-of stateless (that is, I have lots of > hidden <input> elements on those pages). I use those for when I want the > wizard to be able to continue in the middle if the session times out > when a user is halfway through the flow. Yes, the user has to login > again, but they pick-up the flow where they left off. > >> Did you choose to move this state to the client (through cookies) or >> to the database? > > I don't like using the database for scratch work. First of all, it ties > up valuable database resources. Second, it pollutes your schema with > what amounts to temporary data. Lastly, you have to clean up after that > scratch data at some point so you don't fill up your database with > useless junk. I think it's easier to simply allow aborted "transactions" > (meaning multi-page flows) to die along with the session under which > they were running. > >> With session replication between 2 machines, are you effectively >> reducing the capacity of each server, at least in terms of memory, by >> 50%? > > No. You're only reducing the amount of memory available "for sessions" > by half. You can help yourself out a lot by using objects with transient > fields so you don't transmit huge objects across the network and waste > memory on a server that might not get used. Instead, use lazy > instantiation to reconstitute those objects from the database (or > wherever) when they are needed. Only replicate what is absolutely > necessary to recover your state. (This only works well when you are also > using session affinity). > >> Hopefully I'm looking at it the wrong way, because it not, I'm not >> really liking the session replication idea if I'm decreasing hardware >> usage by half. > > I'd have to say that I would rarely recommend session replication just > because the memory, CPU, and network overhead doesn't outweigh the minor > (and hopefully rare) inconvenience of having to re-login when you switch > servers. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGz0z39CaO5/Lv0PARAr9OAKCiB/sk56z7e4kBkPoqHL7QI8wv+ACeO9AA > rsWsRUE4t5JhIbB+dSyS9kg= > =Wypn > -----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] > > > -- View this message in context: http://www.nabble.com/-OT--Session-replication-vs-stateless-tf4325727.html#a12356782 Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
