--- 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.
> 2. Don't use HttpSession (still use cookie) and simply pass the cookie on to
> a stateful session bean, which manages the state.
You keep your states even your server goes down. Less efficient if the
web server and app server are not on the same box.
> 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.
Do you really want to do this? This puts a lot of load on the database.
People have always tried to cache data in the middle to improve performance.
You don't want to go to the database every single time, do you?
> 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.
This is definitely not smart. The client could manipulate the cookie
so you have a big security risk here.
> So I guess the question is, in which tier should state be stored? Servlet
> Engine tier, ejb tier or database tier.
>
I always to put state information as close to the client as possible. When
I need them to persist across multiple boxes, I place them in the mid-tier
(app server)
=====
Cuong Q. Tran <[EMAIL PROTECTED]>
__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/
===========================================================================
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".
