in a prior post, i referred to Ejipt. Imre, the consummate professional
below, didn't trumpet his horn so for those who do not know, Ejipt comes
from Valto and solves the design question at issue in a very elegant manner.
> -----Original Message-----
> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 10, 1999 3:32 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Is something missing in the actual EJB SPECS? Will the
> next version solve this?
>
> I don't believe the spec is lacking in this regard. If you extend your
> object model to allow viewing sets of objects as beans, it becomes easy to
> solve your problem in a quite efficient and effective manner (without
> messing with artificial session beans that do not add any extra value).
>
> It is also interesting that mostly all non-trivial EJB projects require a
> solution to this problem. As was stated previously on this group, it is
> possible to work with very large sets of objects and still have only a
> minimum number of db calls/object instantiations.
>
> Imre Kifor
> Valto Systems
>
> -----Original Message-----
> From: Daniel De Luca <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Monday, May 10, 1999 12:09 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".
