I understand all this perfectly but we are still turning around the problem I've. I still need something else from the specs that will allow me to get the data of the 1,000 rows in the database without the need to call the related objects (which will result in instantiations of them). A sort of lookup method which will return the result of the select statement and not the references to objects containing the data I can get through the getter methods. Daniel Daniel Rickard �berg wrote: > Hi! > > Daniel De Luca wrote: > > > > In spec 1.1, we can read at 9.3.2 p135 > > > > 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. > > You gotta read between the lines though: this only means that EJBObjects > are instantiated for each entity identity. This does not imply that the > entity with the given identity is actually activated. You've only gotten > a pointer to it. Biiiiig differemce. And aboslutely necessary, see > below. > > > 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? > > The container should *not* instantiate the entities. Consider the > following consequence of such an implementation. If a graph of objects > is implemented by saving the primary key of the related beans in the > bean itself, and these references are looked up into real objects in > ejbActivate, then if you do findByPrimaryKey on the root object you will > get the EJBObject to it, and it will be activated. This activation in > turn starts findByPrimaryKey-calls on the related objects (as part of > the dereferencing process). The procedure is recursive so eventually all > objects that can be reached from the root are activated. Not a good > idea, right? > > The only realistic way to implement this is to create the EJBObjects of > the found entities and return these, deferring the actual activation to > the time of the first call. > > A naive implementation of this might have some performance problems, > especially on high-volume systems (lots of objects in the database). If > a finder method returns 1000 objects, which are then called in turn, it > will result in 1001 database calls (each entity is activated > separately). A optimized container would cache the results of the finder > method and reuse this data instead of doing those 1000 database calls. > > Another aspect is that if those 1000 objects were already activated > there is no penalty at all. All EJBObjects and entities are activated > and waiting to be used. Just return them to the user and be happy. Which > leads to an important optimization note: if your container supports > setting the size of the active entity pool and the max. nr of active > entities is known (lets say 100 objects), then you should set the size > to this number. Eventually this will lead to that all entities are > activated and any calls to them will not cause the database to be > accessed. > > Hope this helped some.. > > /Rickard > > -- > Rickard �berg > > Computer Science student@LiTH > @home: +46 13 177937 > Email: [EMAIL PROTECTED] > Homepage: http://www-und.ida.liu.se/~ricob684 > > =========================================================================== > 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
