Assaf Arkin wrote:
> What you are suggesting, if I understand it correctly, is to use proxies
> into entity beans that only load them when they are needed. That would
> be equivalent to just hold a reference to the primary key, passing it
> around, and then loading the entity when you really need it.
>
But I'm not suggesting to hold only the reference. The detail object contains more
information about the entity bean then just the primary key. That way when you are
iterating through the Enumeration you won't have to call a method on an entity bean
since the information you need is already in the detail object.
>
> If you are doing your own SQL selects and bypassing the finders, I would
> like to make a suggestions: bypass the BMP model altogether, use JDBC
> with fetch buffers, cursors and all the other performance tricks. This
> approach certainly scales to one millions results.
>
The entity bean would contain update methods and other methods that modify the
database.
>
> Since you're already handling load/store in your BMP, for large sets of
> information you will find working directly with JDBC not much of a
> difference, and way more controllable.
>
> arkin
>
> dan benanav wrote:
> >
> > I think a good choice when efficiency is of a concern is to use "detail" objects
> > as suggested in the Sun Blueprints guide. A detail object is an instance of a
> > class that contains information about the object but is not an entity bean
> > object. The object may contain the primary key so that the corresponding entity
> > bean can be found.
> >
> > For example you may have an AccountDetail class the contains methods like
> > getUserName and getBalance and getPrimaryKey.
> >
> > There would also be an Account class that represents the remote interface to the
> > AccountBean class. That class could have a method called getAccountDetail that
> > would return an account detail object. You could also write a session bean
> > that has a method that returns an Enumeration of the AccountDetail objects. The
> > method in the session bean would issue one SQL to create the all the
> > AccountDetail objects.
> >
> > One question about this approach is how to handle the case where the Enumeration
> > contains millions of results, or more generally how should the Enumeration be
> > represented. There are probably many ways to do that which I won't get into
> > here.
> >
> > dan
> >
> > James Cook wrote:
> >
> > > Let's face it...99% of the time, the client (and good design dictates that
> > > the client is a session bean) will have to do a findByPrimaryKey in order to
> > > determine if that primary key is of interest to it. If you aren't using CMP,
> > > this results in *very* poor performance especially with larger data sets.
> > > Tricks like Rickard is suggesting are fine, but all of those selects *do*
> > > happen.
> > >
> > > I cannot suggest to my clients that entity bean finder methods are the way
> > > to go. The better approach is to perform the lookup in a session bean. This
> > > isn't a blanket statement, but 99% of the time I think I'm right. ;-)
> > >
> > > Unfortunately, many people design a fair amount of business logic into their
> > > entity beans. When they consider using finder methods via session beans,
> > > they end up having to duplicate some business methods. This isn't a good
> > > idea. Hopefully, they realize that it's not putting the finders in the
> > > sessions that is bad design, but rather putting *any* business logic in the
> > > entity bean is the poorer choice.
> > >
> > > As much as I think Roger Sessions is a Microsoft tool, I think the argument
> > > against entity beans as an inhibitor to scalability/performance is leaning
> > > more and more to his favor. But that is a whole different thread! ;-)
> > >
> > > jim
> > >
> > > > -----Original Message-----
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Assaf Arkin
> > > > Sent: Saturday, January 29, 2000 2:26 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Database Optimization With Entity Beans
> > > >
> > > >
> > > > If you only care about the primary key, then you need that one single
> > > > SQL statement. But if you actually need the entity bean and it's
> > > > identity, then each one has to be loaded separately.
> > > >
> > > > This happens by the container calling ejbFindByPrimaryKey with the
> > > > primary key. The container may do so only when the entity bean is first
> > > > accessed, not all 1+n selects at once, so if you only need two Bobs out
> > > > of twenty, there are only three selects. But if you need all 20 Bobs,
> > > > you get 21 selects.
> > > >
> > >
> > > ===========================================================================
> > > 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".
