Eric Yu wrote: > Presumably, though, to display your "list of content" you will need some > information only contained in your EBs? In that case, all of the EBs will > need to be "instantiated", although I guess a smart EJB container could just > do lightweight instantiations and retrieve state info as needed (?). If the SQL statement returns 1,000 rows from the DB, the EJBFind method will have to instantiate 1,000 EJBObjects.... This is very time and resource consuming (even if your EJB server is fined tuned). 1,000 rows in DB is nothing in comparison to the project I'm working on. Amongst these 1,000 objects, only few of them will be really used by the application (75% of them will probably never be used by the end-user). Making a direct SQL statement, returning the resultset in a serializable form and instatiating (using the FindByPK method) only the necessary beans (those selected by the end-user in the list of content) is much much more efficient. But here we aren't DB independent anymore, and even, no more EJB Server vendor independent because in my case I can use a DB connection pool which requires me to put a specific EJB server vendor parameter to access the pool. > > > If the required display information can be found in the EB primary key > classes, maybe there's a way to get just the set of PK's that match a find > criteria, although the required ejbFind* methods (which _do_ return PK sets) > don't seem to be accessible to EJB clients (just the find* methods, which > seem to instantiate the EBs based on ejbFind results). > > - Eric > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel De Luca > > Sent: Monday, May 10, 1999 12:08 PM > > To: [EMAIL PROTECTED] > > 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".
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
