Jim Frentress wrote: > re 1: not really, it's potentially a separate view of the data. i do agree > that a transparent vendor solution to the problem is nice (like Ejipt's set > stuff for example). however, there are ways to roll this yourself (and make > it portable) by extending a data layer (as we do) in the entity beans > themselves (rather than use session as proposed below). Jim, But you still have to instantiate the entity bean, have you? Maybe I'm missing something here? Could you explain this a little bit more? Thanks Daniel > > > re 2: this is a transaction isolation issue that occurs regardless of the > method you're using to get to the pstore. you do have good control over this > using session or entity wrappers. > > > -----Original Message----- > > From: Anil Nair [SMTP:[EMAIL PROTECTED]] > > Sent: Monday, May 10, 1999 1:39 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Is something missing in the actual EJB SPECS? Will the > > next version solve this? > > > > There are two issues with this solution: > > > > 1. Now, the session beans and the entity beans have to know the schema > > underlying the entities. > > 2. There is no guarantee as to when the EJB container passivates a newly > > created Enitity bean. So you will miss out on some newly created entity > > beans when you do the find. > > > > I would like to see more discussion about this area in general. > > > > Anil > > > > -----Original Message----- > > From: A mailing list for Enterprise JavaBeans development > > [SMTP:[EMAIL PROTECTED]] On Behalf Of James Cook > > Sent: Monday, May 10, 1999 1:27 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Is something missing in the actual EJB SPECS? Will the > > next > > version solve this? > > > > 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". > > =========================================================================== > 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
