Marcus Ahnve wrote:
> > It
> > then becomes a design choice where to store it. Storing it in stateful
> > session beans may limit scalability, as you suspect. What is wrong with
> > storing it in HttpSession state?
>
> Because then every client has to store their own session instead of just
> being responsible of displaying things to the users.
>
[Randy Stafford] It is the responsibility of the presentation layer
to display things to users. The application layer, implemented with
servlets or JSP beans, for example, is responsible for mediating between the
presentation layer and the services layer, and is a logical and likely place
to store conversational state.
> If you add WAP to
> your site for example, that's another client who needs to store the
> session.
>
[Randy Stafford] As has been established in this thread, WAP is
served by servlets. Therefore from the state management perspective, WAP
clients are not significantly distinguished from HTML clients.
> Sure, it might be necessary due to whatever
> performance/scalablility reasons, but I would prefer the stateful bean
> instead.
>
[Randy Stafford] Well, aren't performance and scalability
sufficiently central goals in J2EE to make this state management issue very
important? There are a lot easier ways to build low-scale apps than with
J2EE.
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".
