The thing about a stateful session bean such as a shopping cart is that
it is very useful to have but as you mention if I were Amazon I could
have millions of them sloshing around. However Stateful session beans
like a shopping cart are used very infrequently by the user and their
methods run very quickly in comparison to the gap between method calls.
So the obvious answer to scalable Apps is to use the
Activation/passivation framework that EJB provides. So while the
implementation of it is left up to the App server vendor it basically
revolves around saving the beans conversational state to secondary
storage then removing the bean from memory (or possibly pooling it, if
it is a popular bean), because the client interacts though the EJBObject
they see no change, then when a method is called the App server creates
a new bean of the type needed (or picks one from a pool) and uses the
stored conversational state to populate the bean. This solves a lot of
resources.
the ejbActivate() and ejbPassivate() methods are called when the App
server does this swapping and can be used to free any resources (like
database connections) that the bean holds prior to passivation and
reacquire them after activation.
Karl
Philipp Meier wrote:
>
> On Mon, Mar 13, 2000 at 09:56:10AM -0500, Tom Preston wrote:
> > Well, you can use a servlet session to store any simple JavaBean
> > that encapsulates the ProductIds of the user's shopping cart without
> > using stateful session bean. You could even just keep every item in the
> > cart directly in the servlet session as name value pairs if you want
> > simple.
> >
> > Laird Wrote:
> >
> > Oliver Enseling wrote:
> > > A good example for a stateful session bean is a shopping cart, IMHO.
> >
> > I've always wondered about this example. This means that for every
> > concurrent user on your website, you have to have a stateful session
> > bean active and keeping state. If you have a really good day--say
> > you're Amazon--then that's a lot of thrashing your appserver will get
> > into, right? Is this really the way to write a scalable application?
> >
> > That said, on the other hand, the other choices don't look very good
> > either. You can do a stateless session bean in which case you're
> > basically writing JDBC all day long, or you can do an entity bean, which
> >
> > probably doesn't scale well either.
> >
> > Does anyone have any comments on this?
>
> In either way, you have to store the cart information some where on the
> server-side (assuming no javascript tricking etc.). You are completely
> free to choose wheter you implements the cart storage in the servlet sayer,
> what means in the servlet engine, or in your application layer, what means
> in an application-server (e.g. as a session beans).
>
> I guess an application server handle a high load of session beans much
> better than a servlet engine.
>
> My 2c.
>
> --
> Philipp Meier o-matic GmbH
> Gesch�ftsf�hrer Marlene-Dietrich-Str. 5
> Tel.: +49-(0)731-985 88-870 D-89231 Neu-Ulm
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
===========================================================================
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".
