From: "Mike Shoemaker" <mike@...>

> be. He stated his testing indicated a potential for holding the same
> kinds of information as HttpSessions with reasonably similar performance
> and overhead. Not sure what to think about that one. Ive always stayed

I've seen similar testing results also. However, there are important
caveats:

* There are purchase price benefits to handling your sessions at the front
end, where you use (generally cheaper) Web app servers, vs. at the back end,
where you might be using a high-cost-per-CPU EJB server

* Web app servers are generally more mature and tuned for a large number of
concurrent sessions, since far more people are using that approach

* Most of the nicer web app frameworks will need sessions at that tier, so
you'll probably have sessions there for that reasons.

* I once saw an architecture that had sessions at both the web tier and EJB
tier. That's, in general, a large waste and bad idea. It does double the
work for little extra benefit, and add more failure modes and more need for
complex clustering mechanism, all of which increase cost.


It seems like much of the enterprise development "best practice" community
has congealed around the idea of stateless services in the back-end
application server tier; that model serves a great number of applications
well, though it's not suited for all problems. Notably, if you find
yourself reinventing sessions at the application level, that's a good sign
that you shouldn't be pretending you are using a stateless servive model.


[ Kyle Cordes * kyle@... * http://kylecordes.com ]
[ Consulting and Software development tips and techniques ]
[ for Java, EJB, Delphi, the BDE Alternatives Guide, & more ]