Imre Kifor wrote: > I don't believe the spec is lacking in this regard. If you extend your > object model to allow viewing sets of objects as beans, it becomes easy to > solve your problem in a quite efficient and effective manner (without > messing with artificial session beans that do not add any extra value). Could you be more precise by giving an example? Thanks Daniel > > > It is also interesting that mostly all non-trivial EJB projects require a > solution to this problem. As was stated previously on this group, it is > possible to work with very large sets of objects and still have only a > minimum number of db calls/object instantiations. > > Imre Kifor > Valto Systems > > -----Original Message----- > From: Daniel De Luca <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Monday, May 10, 1999 12:09 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".
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
