Most decent AppServers now offer the ability to persist and failover the
HttpSession object. Check with your vendor.
The simple answer is : "the closer the state is to the client, generaly the
better performing, is your distributed system".
You have to balance the above statement with the hassle and the increase in
bandwidth required for passing state around in your method calls when you
store it closer to the client.
My choice would be to put state in the HttpSession object, and only use a
SFSB if your state is large and is often required between mid-tier calls and
then put it in the database only only if you really require it do so and
have a strong business/technical case for it.
Remember that the nice thing about the HttpSession object is that the
session lifecycle is automatically managed by the appserver.
Also, just to complicate things, there are some appservers that can failover
the HttpSession object, but cannot failover a SFSB.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Cuong Tran
> Sent: Wednesday, 19 July 2000 01:08
> To: [EMAIL PROTECTED]
> Subject: Re: Stateful Session Beans reduce Scalabilty
>
>
> --- 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".
>
>
===========================================================================
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".
