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