The implementation of each find<METHOD>(...) methods invokes a
matching ejbFind<METHOD>(...) method.
The implementation of the find<METHOD>(...) method must create
an EJB object for the primary key returned from the ejbFind<METHOD>,
and return the EJB object reference to the client.
If the ejbFind<METHOD> method returns a collection of primary
keys, the implementation of the find<METHOD>(...) method must create
a collection of EJB objects for the primary keys, and return the collection
to the client.
Daniel
James Cook wrote:
I understand. For CMP beans this would be a problem. The specs already do
implement the finder methods. From what your saying, the specs also force
the instantiation of entity beans that the finder method touches. Is this
the case? Or is it up to the vendors what to do in these CMP-based finder
methods?I agree that this is a performance killer.
jim
----- Original Message -----
From: Daniel De Luca <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 11, 1999 3:35 AM
Subject: Re: Is something missing in the actual EJB SPECS? Willthe
nextversion solve this?> James,
> Yes, you're right, that's what I've done to increase the performance but:
> 1.I don't have the DB independency anymore. I've to write SQL code (I
want to
> have CMP entity bean)
> 2.I don't have EJB Server vendor independency anymore because I need to
get a
> DB connection from the the connection
> pool. To do this I need to put a specify EJBServer parameter in the
> statement:
>
> I think the EJB specs need to provide something more clean...
>
> Daniel
>
> James Cook wrote:
>
> > Most people solve the question you are relating using session beans. The
> > session bean would simply make the appropriate JDBC call to retrieve the
> > list you have in mind. Works great and is very fast. You can even return
a
> > Vector, array, or another collection of EntityPK objects to facilitate
the
> > subsequent lookup of the desired EntityBean.
> >
> > jim
> >
> > ----- Original Message -----
> > From: Daniel De Luca <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, May 10, 1999 12:05 PM
> > Subject: Is something missing in the actual EJB SPECS? Will the next
version
> > solve this?
> >
> > Hi all,
> >
> > Let me explain how I came to this question by first reformulating more
> > precisely my question:
> > Why should the EJBFIND methods always instantiate the entity beans?
> >
> > Why do I ask this?
> > In some cases, we could have the necessity to only get read-only data
> > (perform a sort of lookup) to display them to the end-user so that he
> > will be able to select the right objects he want to work with.
> >
> > Suppose the result of an EJBFIND method is 1,000 rows in a RDBMS, should
> > 1,000 entity beans be instantiated on the server? I don't think so
> > because generally we perform such an operation to display a list of
> > content to perform a selection.
> > It's only when the end-user will select an item of the list that we need
> > to instantiate the corresponding entity bean because we can suppose that
> > the end-user wants to perform some business functions on it.
> >
> > The process of instantiating an entity bean, even if the EJB server
> > provides pooling capability, is very resource and time consuming. I've
> > made some tests with a popular EJB server, installed on a powerful
> > machine; it's amazing how slow this can be.
> >
> > I know that with the current version of the EJB specs (1.0) entity beans
> > are optional but I would like to know:
> > - Are they any EJB server/container vendors that provide added features
> > to allow developers to perform a search without instantiating the Entity
> > Beans for lookup reasons?
> > - Will the next version of the EJB spec (1.1 or 2.0) provide an answer
> > to this problem (lookup mechanism with non-instantiation of entity
> > beans)?
> >
> > I personally think that this non-instantiation aspect (lookup
> > capability) is very crucial from the performance point of view.
> > Something is missing there in the actual specs.
> >
> > Daniel
> >
> >
===========================================================================
> > 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".
begin:vcard n:De Luca;Daniel tel;fax:+ 32 2 714 42 22 tel;work:+32 2 714 42 64 (direct), +32 2 714 42 11 x-mozilla-html:TRUE url:http://www.ficsgrp.com org:<center><a href="http://www.ficsgrp.com"><img SRC="http://www.ficsgrp.com/images/ficstop.gif" ALT="Visit FICS" NOSAVE BORDER=0 height=49 width=150></a></center>;<center>Research & Development</center> adr:;;Excelsiorlaan, 87;Zaventem;Brussels;B-1930;Belgium version:2.1 email;internet:[EMAIL PROTECTED] title:</a><center>Technology Consultant</center> note:<center><a href="http://www.bejug.org"><IMG SRC="http://www.bejug.org/images/gobejug.gif" ALT="Member of the Belgian Java User Group" HEIGHT=31 WIDTH=88></a><A HREF="http://www.politik-digital.de/spam/"><IMG SRC="http://www.politik-digital.de/spam/en/download/spam_h90.gif" ALT="Vote against SPAM!" BORDER="0" WIDTH="92" HEIGHT="39"></A></center> fn:</a><center>Daniel De Luca</center> end:vcard
