A combination can be used:
One could easily write Stateful beans as clients to the Stateless beans to
be used for WAP and thin client apps, and stateful clients with Stateless
Beans for transaction heavy use for scalability reasons
-Rob
-----Original Message-----
From: Marcus Ahnve <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, April 18, 2000 12:55 PM
Subject: Re: Largest EJB Implementation ?
>> > AFAIK it is not a good design to
>> > make the clients session aware --- and thats precisely why stateful
>> > session
>> > beans came into being.
>> >
>> [Randy Stafford] What do you mean by "make the clients session
>> aware"?
>
>I don't know if this is Ana's view, but to me it means that the client
>of the EJB has to know that there is a session involved and store their
>own state.
>
>*snip*
>
>> 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. If you add WAP to
>your site for example, that's another client who needs to store the
>session. Sure, it might be necessary due to whatever
>performance/scalablility reasons, but I would prefer the stateful bean
>instead.
>
>Regards
>
>/Marcus
>
>Marcus Ahnve
>Sun Java Center
>Sweden
>
>===========================================================================
>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".
