----- Original Message -----
From: "Dave Ford" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 18, 2000 10:11 AM
Subject: Stateful Session Beans reduce Scalabilty
> I was just reading an older thread in which someone pointed out that
> "Stateful Session Beans reduce scalability". Then multiple responders
> concurred with his point. Then the idea of using using Stateless session
> beans to achieve better scalability came up.
Stateless beans *do* scale better than stateful. That doesn't mean that you
should avoid stateful session beans when your design calls for them. They
are simply another option.
> But this logic doesn't make sense to me. If you need to maintain state (as
a
> shopping cart does) use need to maintaining state. So the question "Use
> stateful or stateless session beans?" isn't the write question to ask. The
> question should be, "WHERE to maintain state?". As I see it, there are 4
> possibilities (assuming web based app):
Past threads emphasize this point very much. One size solution, however,
does not fit all situations. Where you maintain state depends on many
factors such as scalability, failover, state size, contention, and
environment.
> 1. Use HttpSession (which passes sessionid as cookie or encodes it into
the
> URL)
Good for many state requirements. Simple and lightweight, state is held in
memory. Most implementations are susceptable to failover headaches. Frankly,
most applications can withstand a loss of state if a webserver goes
down...others cannot.
> 2. Don't use HttpSession (still use cookie) and simply pass the cookie on
to
> a stateful session bean, which manages the state.
Stateful session beans do not need a cookie. Store a handle (or remote
reference) to the stateful session bean in the user's HttpSession object.
> 3. Don't use HttpSession or Stateful Session Bean, but rather, pass cookie
> all the way to the database and have the database hold all the state.
I am assuming you mean to use the cookie value as a primary key to a
database record. This is the best portable, fault-tolerant solution
available right now. It is also relatively slow on the performance scale.
> 4. I guess you could pass ALL the state back and forth to client everytime
> as a giant cookie, the no server has to store the state. But this desn't
> seem smart.
Nope
> But my main question is, if SCALABILITY is main goal, where is the best
> place to store state?
Given that goal, it is fastest, and most scalable, to store state in the
webserver's memory. That is done by using the HttpSession object.
jim
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
