The container does not need to hold in memory N number of instances where N
is the number of clients who have not timed out. Only the number of
concurrent clients.
<vendor-faq>
http://www.inprise.com/devsupport/appserver/faq/Availability_Scalability_Per
formance.html
Passivation and Reactivation of stateful session beans. Most of the
implementations out there do the Passivation correctly but have to keep some
pointer information in memory to be able to reactivate the session bean. We
have 0 (zero) bytes in memory for each passivated session bean. This is a
HUGE advantage since at some point other EJB containers will reach their
memory limit but with Inprise EJB container you are not limited.
</vendor-faq>
The benefits of stateful session beans include:
<vendor-faq>
http://www.inprise.com/devsupport/appserver/faq/Availability_Scalability_Per
formance.html
3) Stateful Session Beans. Stateful SB are passivated into a JDatastore
database, which is available via an IDL interface. This Session Storage
service can either run in process, or out of process. If run out of process,
multiple Containers can share a single Session Storage service. So, let's
assume we have two Containers (one in VM 1, and one in VM 2) running
replicated Stateful Session Beans, and the Session Storage service running
in VM 3. Let's say a client creates a shopping cart (a Stateful SB) in VM 1.
The shopping cart will be automatically passivated every 5 seconds (a
tuneable parameter). Then let's say that the client puts a book into the
shopping cart, and then thinks for a while. The shopping cart will be stored
persistently within 5 seconds in the Session Storage. Now, lets say VM 1
crashes. The shopping cart EJBObject will automatically fail-over to VM 2.
This container will see that it doesn't have the state for the user's
shopping cart activated, and it will load the state from the storage server
(VM 3). The client will now continue using the shopping cart with its
contents intact.
</vendor-faq>
William Louth
> -----Original Message-----
> From: Craig McMurtry [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 17, 2000 5:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Largest EJB Implementation ?
>
> I do not find either of these solutions attractive. The stateful session
> bean
> will compromise scalability by allocating memory for each user, while, if
> I am
> not mistaken, the httpsession object will attempt to download cookies to
> the
> browser's host--an attempt that is not guaranteed to succeed. My
> preferred
> solution is to keep some of the state in hidden input controls within the
> HTML,
> amongst which would be a GUID by which bulkier quantities of state (more
> than a
> shopping basket: the responses to a survey or regulatory form for example)
> can
> be retrieved from a data store.
>
>
>
>
>
>
> "Bhattacharyya, Ana" <[EMAIL PROTECTED]> on 04/17/2000
> 11:31:45 AM
>
> Please respond to A mailing list for Enterprise JavaBeans development
> <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: Largest EJB Implementation ?
>
>
>
> Hi Sripada
> Its true that u can maintain the session in the servlet side.
> Lets take the most popular example -- a shopping cart. Here the end user
> will go on adding/removing the items in his cart and the web page goes on
> updating/showing the items that he has chosen so far and the total price
> etc
> etc.
> Now lets take the servlet session paradigm. Here u can represent the cart
> by
> the httpsession object and go on doing session.putValue.. and for each the
> servlet can ask the stateless session bean to calculate the price of the
> selected items. And when the nd user finally submits -- then the servlet
> finds out all the items he has selected and gives it to the stateless
> session bean for calculation etc etc.
>
> Now the other way of doing this is --- instead of stateless session bean
> --
> have a stateful session bean and make the servlet act just as a gateway to
> the stateful bean. The stateful session bean mailtains all the cart
> details
> --- so effectively the stateful session bean becomes a shopping cart
> instead
> of the servlet/httpsession becoming the cart.
>
> Now with the 1st one -- take the case of a non http client -- who will not
> want to access the application logic using servlets --- then that client
> have to maintain the cart on his own. But the 2nd case is more effective
> in
> the case of a non http client. Or even if u take a non servlet client like
> say cgi script which does not have those sophisticated session apis ---
> their the 2nd soln will be better.
>
> This is entirely my feelings --- I may be wrong and any comments is
> appreciated.
> TIA
> Anamitra
>
>
> -----Original Message-----
> From: Sripada Srinivas
> To: [EMAIL PROTECTED]
> Sent: 4/15/00 6:16 AM
> Subject: Re: Largest EJB Implementation ?
>
> Hi Ana,
>
>
> > Does
> > it point to the fact that their requirements were pretty simple or
> they did
> > some designs like maintaining sessions in the web server and not in
> the ejb
> > server??
>
> **********
> I am wondering how do you manage this. If the bean is contacted through
> the
> servlet, the session maintainance needs to be carried out by Servlet
> only.
> Correct me If I am wrong.
>
> ***********
>
> >
> > I really dont get what value add I am getting from using EJBs if I
> dont go
> > for entit beans or stateful session beans. AFAIK it is not a good
> design to
> > make the clients session aware --- and thats precisely why stateful
> session
> > beans came into being.
>
> ******************
> Is it the reason??
> ******************
>
> > But then people say it is too slow and go back to
> > 1> Either storing the session info in HttpSession in the servlets
> engine OR
> > 2> Storing session info in a hastable like data structure in the ejb
> server
> > side -- something like a dependent object to the ejbeans.
> > ie back to square one!
>
> *************
> It really baffles me how does the stateful session bean can make a
> client code,
> not take care the responsiblity of the session tracking??. I am talking
> about
> the scenario using the servlets, which is quite popular.
> *********
>
> --Sripada
>
> ========================================================================
> ===
> 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".
>
>
>
>
>
>
>
> ----------------------------------------------------------------
> The information transmitted is intended only for the person or
> entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use
> of, or
> taking of any action in reliance upon, this information by persons
> or
> entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the
> material
> from any computer.
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
