This depends on the app server. For instance, Weblogic will fail-over the HTTP
session state, but not a stateful session bean, so if fault-tolerance for your
state information is important to you, you might want to think about using HTTP
session state.
Other app servers will do this differently.
--- Dave Ford <[EMAIL PROTECTED]> wrote:
> 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.
>
> 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):
>
> 1. Use HttpSession (which passes sessionid as cookie or encodes it into the
> URL)
The problem with this is if your server goes down, you lose all your
state and you dont use the load-balancing, fail-over features provides by
most app servers. I'd choose this if I dont care about losing states when
my server dies.
<snip>
===========================================================================
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".
