Dain,

I've read your email on how to use the eager/lazy loading features.  I'm not
sure if this is the same thing as danch's <read-ahead> feature.  Your
eager/lazy loading seems to be focused around LoadEntity, where danch's
read-ahead happens on the finder call itself.  I really should examine your
code(sorry, too lazy at the moment), but eager/lazy loading seems to
optimize on limiting what field you load from the database, where danch's
read-ahead deals with when do you read a beans fields.  With read-ahead
there is no longer n + 1 select calls when doing a finder call then
subsequently accessing the beans returned by the finder.  Do your
optimizations take this into account?

Bill

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Monday, June 25, 2001 6:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] CMP 2.x Quick How-to
>
>
> Thanks for the comments...  (Dam it is hot here in Minneapolis, 97 degrees
> F, I got to get my airconditioner down from the attic and installed ASAP)
>
> > Maybe as a first question - how 'done' do you consider the basic
> > architecture of the CMP2.0 module? Done enough that there aren't going
> > to be any major structural changes, or might it get turned upside down?
> >
> > As a frame of reference for my frame of mind, in my statements/questions
> > below, I'm assuming that it _won't_ get turned upside down.
> >
>
> I consider CMP fields done, and don't expect them to change much.
> I am just
> starting on designing relationships and this might cause some changes.  As
> for queries, they are completely up in the air.  The EJB-QL implementation
> may cause some global changes, but I don't think that will happen.
>
> > >
> > > The query-method element is right out of the EJB 2.0 spec. The
> > > <declared-sql> element is similar to jaws finder element,
> except I have
> > > broken the query element into from and where.
> >
> >
> > Thank you. having them combined made some things really painful. This is
> > something I was going to change in JAWS.
>
> I saw you comment in the code and broke it in two...
>
> > > I also support order as jaws
> > > did.  The new code doesn't have the new pre-load logic, but I will add
> > > something similar in phase 3, where I'll add ejb-ql support.
> >
> >
> > Do you have any objection to Bill or I getting the initial underpinnings
> > in there now? It's changed quite a bit since the version of JAWS that
> > you (apparently) based your new work on.
>
> I only implemented queries so people can play with my code.  I'm
> not sure if
> it would be worth your time to mess with my query code as most of
> it may go.
> I also plan on implementing the <eager-load> stuff on a per query basis.
> That way you can get just the data you need back.
>
> > On a related (triggering, in fact) note: do you see your CMP
> > implementation obsoleting JAWS, or augmenting it? Personally, I had
> > intended on taking a chainsaw through JAWS anyway, so I wouldn't mind
> > seeing it obsoleted. If it's obsoleted, I really think we may as well
> > get more people than you working on it - hence the above question.
> >
> > Or if not, I'll find something else to do.
>
> I do intend on obsoleting JAWS; the new stuff is a rewritten fork of JAWS
> (the architecture rocked).  The new code is backwards compatable with EJB
> 1.x CMP (it is required by the spec).  Most of what is left is
> mostly a one
> person job.  Most of it is design, the code should be fairly
> simple.  I have
> lots of time to work on this (I'm on vacation for several months,
> benefit of
> being an independent consultant).  If you really want to help and see a
> section to break off, email me.  (but EJB-QL is mine... i've been jonesing
> to write it).
>
> > >
> > > If you find any bugs or would like to request a feature, please email
> me. I
> > > will fix bugs as they are discovered, and feature req1uests I will
> > > definitely think over.
> >
> >
> > I really think that these should be posted on the sourceforge site -
> > bugs because it lets us get more bandwidth - people other than you can
> > fix the bugs, which means that more eyes will be on the code, which will
> > lead to better code. That's why it's open source, after all.
>
> I agree, it could get lost in my mail box.  I could die and it
> would be lost
> forever.  But I may not notice it if it is only posted to source forge.
>
> -dain
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to