William Louth asks:
> > [Randy Stafford] both entity beans and stateful session beans inhibit
> > scalability. But, take the good and leave the bad.
> >
> Could you please explain the stateful session beans part. I would like to
> hear an alternative to this which does have the *your* scalability
> problem.
> Do you propose that the state be transfered back and forth between client
> and server? Are you designing systems which really do not need to have
> session state? How would you handle the shopping cart example...servlets?
> Sorry if this is already documented in your pattern/design book...I have
> not
> finished reading it.
>
[Randy Stafford] In general I agree with the argument that,
assuming some sort of pooling mechanism and some other place to store
conversational state, a much smaller number of stateless session beans can
do the same amount of work that a much larger number of stateful session
beans can do, with much lower resource demand on the server. This is
because a stateful session bean just sits around hogging up resources and
remaining unutilized between client invocations, and the container might
have to spend cycles managing its memory consumption via activate and
passivate, whereas a pool of stateless session beans is highly utilized by
multiple clients, and can therefore remain small and lightweight. The
argument is presented quite well by Richard Monson-Haefel in his book
Enterprise Java Beans (O'Reilly, 1999) on pp. 42, 51-52, and 175. I do not
propose that state be maintained by transferrence between client and server
(of course, this is how the client gets its state in the first place, and
the client presumably passes back some of this state as parameters in server
calls). The distributed Java systems I've worked on recently have all had a
need to store session state, either in Swing UIs or in servlet engines. In
the FoodSmart example application, the shopping cart state is stored as
HttpSession state in the servlet engine, but the user has the option to
persist his shopping cart (in a DBMS) for a later visit (in that app we
weren't worried about fail-safe session state).
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
===========================================================================
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".
