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