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

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

Reply via email to