> 2. Entity beans do some kind of usefull data caching when they
> are well
>modelled. The more common situation is to use entity beans that
>represent real live actors (Employee, BusinessPartner, Customer) or
>object belonging to them (Contract). This kind of entity bean are often
>loaded once by the actor and more often browsed than changed. So after
>the first lookup (2 DB calls), many "get requests" are sent to the bean
>(no DB calls). If you use stateless bean here, you will send it to the
>DB for each get request (no caching capability).
Actually I don't think that Dave is proposing using Session Beans for all
his data access. His idea doesn't eliminate the use of EB's. He is merely
introducing another option to re-use database access logic.
>Some rules:
> - Replace entity beans by stateless beans for "objects" that are less
>interactive and often subject of mass update. The more current using
>logic should be: lookup a list of row ids, iterate the list and update
>each row. Using stateless beans for this purpose, you save a lot of
>useless ejbLoad calls.
This is the path a lot of people use (use Session beans because Entity
beans are too expensive Design Pattern) and what I think Dave was thinking
of in general...
Cheers,
eddie
==========================
===========================================================================
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".
