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