let's forget about the stateful/stateless debate...i was really asking why
the blueprint made the shopping cart a session bean in the first place since
to me it's not a distributed component. what are the tangible benefits of
making it a session bean. if people are saying that object pooling performs
better, even with passivation/activation overhead, then i can buy that.
failover...app servers support http session replication as well. maybe i
didnt read the blueprint too carefully but i didn't see them using
declarative security for the shopping cart and it didn't look like the
shopping cart needed transaction support. so why is it a session bean?
----- Original Message -----
From: "Krishnan Subramanian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 11:54 AM
Subject: Re: [EJB-INT] ejb - distributed components
> tinou,
>
> its the age old argument of stateful vs. stateless.
>
> with most ejb vendors, there is some form of
> passivation mechanism which is triggered when
> the number of [active] stateful bean instances
> exceeds a certain (usually configurable) limit.
>
> so the memory usage will not go overboard when
> the number of users shoots up. (this passivation
> could be done with entity beans as well)
>
> note that there will be some overhead when
> passivated beans (session or entity) have to
> activated again by reading from secondary
> storage ... but on modern systems, this will be
> relatively unnoticeable.
>
> to preempt your next question, quite a few
> ejb vendors also provide for failovers for
> stateful session beans (I know Borland and
> BEA do)
>
> -krish
>
>
> ----- Original Message -----
> From: Tinou Bao <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, April 26, 2001 3:13 PM
> Subject: ejb - distributed components
>
>
> > hello ejb gurus,
> >
> > ejbs are meant to be distributed components that handle security,
> > transaction, lifecycle management, etc. for you...my question is if you
> know
> > that your component will not be a distributed component, but may still
> need
> > other services that the container provides, does it make sense to model
> your
> > component as an ejb? take, for example, the pet store demo in the
> > blueprint. the shopping cart is model as a stateful session bean. why
> > would this need to be a distributed component? if pets.com architected
> > their system this way and get 100,000 online shoppers the system would
> have
> > 100,000 stateful session beans floating around. seems to me that this
> would
> > not be very scalable or at least harder to scale. another question i
have
> > is with the popular session facade pattern does it make sense to make
the
> > entity beans entity beans.
> >
> > any and all comments are appreciated,
> > tinou
> >
> >
>
===========================================================================
> > 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".
