Hi,
lets be a bit situative when modeling. Can you cite one example where
you will need to update 100 entity beans at once? If you often have such
an operation into your application (i.e. daily), then redesign it.
There are cases where this happens, but such situations are so rare that
you don't need to change the entity bean to a session bean because of
them.
Concrete case EmployeeEntityBean: You will need to update the salary of
10000 employees, but this happens once a month and not evry morning. The
bean is more used by employees every day for common tasks (getting
address of the coleague, schedulling a meeting). I won't change change
the EmployeeEntityBean to EmployeeStatelessSessionBean because of this
one case. I could run the expensive operation in the nigth when the load
is down.
/Francis
"Pandurangan, Soundar" wrote:
>
> Well, if there are say 100 calls to the DB, then, if we go by the Entity
> Bean (rather than DAO), then that many wrappers (for instance, in case of
> PKclass) need to be maintained and they in turn need to be utilized by the
> session beans, whereas, if we use the DAO sessions (stateless) we are going
> to hit the DB directly and that reduces a lot (and lot and lot) o/h for the
> pool. You could very easily visualize the difference.
>
--
[EMAIL PROTECTED]
MATHEMA Software GmbH
N�gelsbachstra�e 25 b
91052 E r l a n g e n
D e u t s c h l a n d
Tel +49(0)9131/8903-0
Fax +49(0)9131/8903-55
http://www.mathema.de
===========================================================================
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".
