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 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".
