The system wont have 100,000 stateful instances floating around.
Probably, if you are using a good machine and a good app server the system
will have, for example, 1,000 stateful serving 100,000 shoppers.
See page 115 of Edd Roman�s "Mastering Enterprise Java Beans".
-----Original Message-----
From: Tinou Bao [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 11:14 AM
To: [EMAIL PROTECTED]
Subject: [EJB-INT] 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".
