-----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]
