tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [OT] Session replication vs stateless
Date Fri, 24 Aug 2007 21:26:15 GMT
Hash: SHA1


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

- -chris
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message