But am I missing the spirit of the original post (long since buried)? Why
can CMP enjoy optimizations over BMP? Is it just in certain circumstances
that I haven't considered?
thanks for the insight,
jim
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jon Ferguson
> Sent: Monday, October 04, 1999 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Doubts about Entity beans, Should we use them?
>
>
> Hi James,
>
> Just a small note: the spec. does not require that we "instantiate" all
> those enterprise beans when the bean goes from the pooled to ready state.
> True the objects take up space - but we can do lazy evaluation as far as
> reading values from the data base... Say when the remote application calls
> getCustomerName(). So with lazy eval. grabbing out the number of large
> accounts is possible without fully instantiating any of the beans - even
> though with the enumeration interface you still need to do the iterations.
>
> Hope this helps,
>
> Jon
>
>
> -----Original Message-----
> From: James Cook [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 04, 1999 7:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Doubts about Entity beans, Should we use them?
>
>
> I'm sure I'm missing the point. We are trying to demonstrate why
> BMP cannot
> be optimized as much as CMP. We are also looking hard at the finder method
> for entity beans. To find orders with balances > $100 we would have the
> following BMP query in the Order home...
>
> public Enumeration ejbFindByBalance(BigDecimal amount) throws ...
>
> in this finder we will issue the appropriate SQL to create a bunch of
> Primary Key objects and stuff them into an enumeration.
>
> If the client is the GUI side of an application and wishes to stuff the
> customer names from these orders into a list box, a separate remote call
> would be necessary to obtain the names. This would be required
> whether using
> CMP or BMP, and you should be whipped with a wet noodle for not using a
> session bean.
>
> So what's the deal with CMP? Can the containers optimise the subsequent
> remote getCustomerName() calls because they instantiated all of those
> objects when they did the original finder query? If so, wouldn't
> this be an
> incredible waste of time if my client simply wanted to report the
> number of
> large orders?
>
> I'm not sure if I see the scenario that is causing the grief. Please help.
>
> jim
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Raber
> > Sent: Friday, October 01, 1999 6:35 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Doubts about Entity beans, Should we use them?
> >
> >
> > Muly,
> >
> > Yes the spec is written that way. But there is nothing that
> says your BMP
> > implementation can't cache the results of the initial query. Some BMP
> > generators <vendor> Cocobase </vendor> will write this code for you...
> >
> > -Chris.
> >
> > > -----Original Message-----
> > > From: Muly Oved [SMTP:[EMAIL PROTECTED]]
> > > Sent: Friday, October 01, 1999 4:51 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Doubts about Entity beans, Should we use them?
> > >
> > > >If the original request was "Get me all employees", then the
> > > corresponding
> > > >find()
> > > >method in case of BMP might use one query
> > >
> > > >SELECT PKEY, FNAME, LNAME FROM EMP
> > >
> > > >to build the enumeration of primary keys AND entity bean for each
> > > employee,
> > > >which
> > > >will remain in cache until used by the caller.
> > >
> > > I don't think this can be done with BMP, as the result of the ejbFind
> > > should be an enumeration of primery keys, then the continer take every
> > > primery key and use ejbLoad to load the rest of the fields.
> > >
> > > The spec limit the way this find is solved, this is where CMP has more
> > > space for optimization.
> > >
> > > muly.
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
>
> ==================================================================
> =========
> 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".
