Hello Cuong and Dave,
Cuong Tran wrote:
> --- 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.
>
Why would application servers handle HttpSession state in a less "robust" way than
state in a stateful session bean? Normally, your application server will indeed
keep the session state between restarts (of course this can fail for obvious
reasons, but it can for state in a stateful session bean too). It will also be
able to replicate the http session state to other instances of the application
server, enabling load-balancing and fail-over.
Of course, session replication needs bandwidth, and in a big clustered environment
you will probably want small islands of servers where all state is replicated,
rather than replicating the session state to all servers. Then you need to make
sure that your load balancer will keep a user within the island where his state is
valid.
I know we (Orion) provide http session state replication and I'm sure some others
do as well.
The original question posted by Dave ("if SCALABILITY is main goal, where is the
best place to store state?") is a very interesting one, which means it doesn't
have one simple answer. While some state might have a very natural home in a
stateful session bean (for example the cart contents of an EJB based online shop),
other kinds of state are more suitably placed in other parts of the system. And
the assumption that keeping the state on the client is bad is not always true. You
have to compare the extra bandwidth needed for client to server communication, to
the extra bandwidth needed on the server for state replication (if you need
fail-over or load balancing that is) and the number of clients that the server
needs to hold state for.
Let's say that the only state your web-application needs is a String saying what
the user's chat-nickname is, and you run a chat site with 500,000 concurrent
users. The users only access pages about once every 30 minutes when they switch
chat rooms, and the rest of the time they spend chatting away in an applet on your
site. If you choose to store this state (the chat nick) on the server you will
obviously end up with pretty much state on the server. This might not matter much,
but if you want fail-over to work transparently without users noticing they're now
coming in to another server you need to replicate this state. Compare that hassle
and overhead to just keeping the state in a cookie on the client and let him send
it (perhaps 20 extra bytes) when he requests a new page every 30 minutes. This
scenario might seem kind of artificial, and I'm sure someone could give a better
example, but there are cases where storing state in web applications on the client
side isn't neccesarily a bad idea.
And in the same way, storing the state in a database can also be good under
certain circumstances.
Regards,
Karl Avedal
The Orion team (http://www.orionserver.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".
