> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Filip Hanik
> a join, the performance would still not be good since an entity bean is a
> very heavy weight object.
I suppose this is what I disagree with, but only in a relative sense. I will
defer that an entity bean is *heavier* than a stateless session bean, but it
is not a *very* heavyweight object by its nature. It takes no more time to
pull an entity bean out of a pool, than it takes to pull a SLSB.
In any meaningful application, an entity bean will have to be synched with
the database before it is used. This takes time, but must be done in any
architecture. With the appropriate lazy-loading techniques this is moot, and
Entity Beans (EBs) make this a very simple activity.
The only key difference I see between EBs and some other persistence pattern
(whether it be JDO or DAO) is the transaction that is necessary to access an
entity bean even for read access. I don't know about you, but in my EJB
containers this is a blip on the radar screen in terms of memory consuption
and performance.
> an entity should, IMHO, represent a more complext transactional data
> structure that needs to be shared among different clients in order to be
> useful.
Even if I had a simple 2 column table of reference data, I would still
choose to represent this as an entity bean in most systems. There are
exceptions of course, but if the reference data can *ever* be modified, then
an entity bean is the appropriate structure.
jim
===========================================================================
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".
