Other uses may be
- Your application architecture does not specify that the client is always a
servlet. It could be one of Java App/Servlet/C++ app/another EJB application
etc. etc. In that case it is best that you store common state in the middle
tier and manage it there. (though as usual apply a lot of caution).
- As the statless SB is an extension of the client, ideally anything that
represents state in the client can be done here, but within the context of
transactional, security and robustness that the middle tier will provide.
Again apply caution because of the obvious performance reasons.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Regan
> Sent: Tuesday, 14 March 2000 07:15
> To: [EMAIL PROTECTED]
> Subject: Re: Is it worth to use a StateFullSessionBean
>
>
> Would you? It seems to me you could place these in
> your HttpSession object, or am I missing something
> basic here?
>
> I keep hearing we shouldn't be using Stateful beans
> because the performance is so bad. Is there any cut
> and dried answer as to when we should spring
> for them and when we shouldnt?
>
> The only logical answer I have been able to come up
> with is that we should use stateful when there is a
> multi-stage transaction taking place, ie. a bank app
> or the like, where we want a bunch of actions to
> happen or none at all. A shopping cart
> has many products, but that is just using the
> session bean for temporary storage, and then doing
> an order commit at the end via your entity bean.
>
> -dr
>
> btw. what is with all of these appserver vendors
> posting to the newsgroup? talk about listening to
> biased opinions. I'd love to hear opinions of
> developers on their choices, but I find a lot of these
> testimonials suspect at best.
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Oliver Enseling
> Sent: Thursday, March 09, 2000 11:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Is it worth to use a StateFullSessionBean
>
>
> Sesh:
>
> A good example for a stateful session bean is a shopping cart, IMHO.
> The state of the shopping cart is made up of the selections a shopper
> makes while shopping at an online store. Only, when the shopper
> proceeds to checkout, do we actually transform the shopping cart
> into an order.
>
> During the checkout process, we can create appropriate entity beans to
> represent
> a persistent order. Note that the shopping cart state needs to be
> preserved
> only as
> long as the shopper is 'in' the store.
>
> If you were to implement a shopping cart without SFSB, you need to provide
> entity beans to cache the in-store selections of a shopper, which IMHO
> is not appropriate and very likely less performant and scalable than using
> SFSB.
>
>
>
> -----Original Message-----
> From: Sesh Kumar [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 07, 2000 10:13 AM
> To: [EMAIL PROTECTED]
> Subject: Is it worh to use a SateFullSessionBean
>
>
> Hi,
> I am quite unsure If I should use a StateFullSession thou' I used it. In
> my applications I am able to do every thing that I can do with a StateFull
> Session Bean using a StateLessSessionBean and an EntityBean. And I have a
> feeling that if I use a SFSB it is going to impact the performance. I am
> passing the sateinformation to the SLSB to every business method, I know
> that if it is a SFSB i can do it using single persistant
> field(CMP or BMP).
> But is it worth to give each client a SFSB to work with. Could some one
> provide a good example to prove that I am wrong ..
>
> thank you
> sesh.
>
> ==================================================================
> =========
> 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".
>
> ==================================================================
> =========
> 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".
>
>
===========================================================================
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".
