Hi Adena,
This is all about trade offs. Dave you talk about memory constraints but
what about performance, code bloat and maintainability. With the session
bean using the jdbc resultset you have now spread the database knowledge
across components (session and entity beans) leading to more code and a
maintenance nightmare if for some reason you need to alter you db schema or
possibly change database vendor. Any future persistence optimizations done
at the entity bean layer will now have to be reflected in the session bean
layer. The performance problems then kick into play when vanilla entries in
the collection are processed, possibly changed, since you will not avail of
many features built into the cmp engines of appservers including ours. Of
course you could always write this code to detect changes but then you are
increasing your code bloat and probably doing more infrastructure building
than business logic development. Not to mention that the business logic code
in the entity bean layer must also be copied over to the session bean; that
is if your entity beans are not just data wrappers which is wrong. So you
have a session bean with lots of jdbc and entity logic all mixed together.
I have a DBA friend who says 'A good DBA is someone who does nothing'.
Strange that he also says 'A good DBA gets paid well'.
My rule always use a session bean which uses a home to find a bean or beans
to be changed.
Filtering at the database level will most likely give a greater performance
boost than any other technique - locality principle. When you must return N
number of beans set a flag in the container to load the state while doing
the find i.e. select. Our application server supports all this I suspect
others do also; the degree of power and ease of use is another story
especially when it comes to finders and their syntax.
Dave regarding the N*users are you saying that all users hit the application
server simultaneously and that each requests is identical and accesses a
large portion of the table if not all. This is not typical and an extreme
case at that. The 'one instance' throws me since this would imply that
there is no concurrency issue thus the N*users number would be incorrect
useless you are saying that there is no garbage collection of object pooling
mechanisms in place.
William Louth
Inprise
www.inprise.com
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
Sent: Monday, August 28, 2000 11:44 AM
To: [EMAIL PROTECTED]
Subject: Re: Does it ever make sense to put a multi-bean-returning find
methodin an entity bean?
But there is one major difference. For the entity bean finder you will have
N (n=rows) instances of an entity bean (and possible N*users) in memory for
every row. Whereas one stateless session bean may be able to service
multiple users and does not need one instance for every row. Each instance
is a space in memory.
IMHO I always use a session bean to find and an entity bean to change.
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jean-Baptiste Nizet
> Sent: Monday, August 28, 2000 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Does it ever make sense to put a multi-bean-returning find
> methodin an entity bean?
>
>
> Adena Galinsky wrote:
>
> > Hi everyone,
> > Everything I've been reading seems to indicate that calling the
> find methods
> > in entity beans just wastes time and resources. They seem to recommend
> > writing find methods in session beans, which issue JDBC calls
> directly and
> > return an array of primary keys.
>
> You should check your sources, IMHO.
> If all you want is an array of primary keys, the I don't think
> your home-made
> finder will perform substantially faster than the entity bean finder.
> On the other hand, if you want to load the state for the whole
> collection of
> beans, then yes, using a basic finder is not efficient, since it will make
>
> * 1 DB call to get the collection of primary keys
> * n DB call to load the state for each bean
> * n DB calls to store back the state of each bean.
>
> However, any decent AppServer should help you avoiding the last n
> DB calls by
> detecting read-only methods, either automatically, either with
> some help from
> your part.
> Moreover, if you're using CMP, the CMP engine should be smart
> enough to let you
> specify that you want the finder to load the whole state, and not
> just the PKs.
> In this case, you still use entity beans witout custom JDBC code,
> and you have
> only 1 DB call.
>
> JB.
>
> > Given that this is faster and lighter
> > weight, why would we ever write a find method in an entity bean which
> > returns more than one instance of a bean?
> > -Adena
> >
> >
> ==================================================================
> =========
> > 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".
>
> --
> Jean-Baptiste Nizet
> [EMAIL PROTECTED]
>
> R&D Engineer, S1 Belgium
> Kleine Kloosterstraat, 23
> B-1932 Sint-Stevens Woluwe
> +32 2 200 45 42
>
> ==================================================================
> =========
> 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".
