Jon, On Thu, 6 May 2004 13:28:39 -0700 (PDT), Jon Wilmoth wrote:
> >Thanks for the responses! I think I'm going to try >the "pre-iterate" approach as it will allow me to >handle exceptions in the controller tier instead of in >the presentation tier. > >I think that sort of flexibility would be greatly >appreciated by people trying to tune their >castor-based applications. > >Speaking of tuning...it would obviously be faster to >execute one SQL statement that brought back the parent >and all the children when a relationship field is NOT >lazily loaded instead of issuing what appears to be >one query for the parent and n queries for the >children. Well, that's exactly the behaviour you get if you do not declare a collection as lazy-loaded. Iow, if you have a collection field within an object,a nd you define lazy="false", Castor will perform one big query and load the complete object graph. Now, if you happen to have many children hanging of the main object, you'll have to come up with your own set of rules where to turn lazy-loading on and off. Werner Has anyone raised this topic as a potential >change already? It seems like a significant >performance issue if you have any number of child >objects in a relationship at all... > >--- Werner Guttmann <[EMAIL PROTECTED]> wrote: >> >> Jon, >> >> just picking up on one of your questions below, as >> Patrick has provided answers to everything else. >> >> Werner >> >> On Thu, 6 May 2004 17:22:43 +0100, Patrick van Kann >> wrote: >> >> >Hello Jon, >> > >> >Unfortunately, lazy loading can only be used in >> short transactions. >> > >> >The underlying RelationCollection holds a >> relationship to the transaction context in which the >> parent object is loaded, which it calls upon to load >> >> objects when iterator.next is called. If you have >> closed the transaction that loaded the parent >> object, it can't lazily load when you call >> iterator.next(). >> > >> >One strategy is to "pre-iterate" in the >> transaction, which could work in a situation where >> you are providing "pages" of results from a database >> query. In >> other words, iterate the first 10 items in the lazy >> loaded collection before closing the transaction and >> returning the object. >> > >> >Otherwise, you need to load the object from within >> your JSP page/presentation tier. If it is jsp, you >> could use the castor taglibrary to do this quite >> easily: >> > >> >http://castor-taglib.sourceforge.ne >> > >> >Hope this helps, >> > >> >Patrick >> > >> > >> >-----Original Message----- >> >From: Jon Wilmoth [mailto:[EMAIL PROTECTED] >> >Sent: Thu 5/6/2004 4:59 PM >> >To: [EMAIL PROTECTED] >> >Subject: [castor-dev] [JDO] lazy loaded collections >> > >> > >> >After turning on logging on my JDBC driver, I >> noticed >> >that a seperate query statement was issued for each >> >child object in a parent child relationship (i.e. >> >ProductGroup --> Product). >> > >> >Query "SELECT >> >>AA_PRODUCT_GROUP.PROD_GROUP_ID,AA_PRODUCT.PRODUCT_ID,AA_PRODUCT_GROUP.CATEGORY >> >FROM AA_PRODUCT_GROUP LEFT OUTER JOIN AA_PRODUCT ON >> >>AA_PRODUCT_GROUP.PROD_GROUP_ID=AA_PRODUCT.PRODUCT_GROUP_ID" >> > execution time: 0 result set fetch time: 0 >> > >> >Followed by... >> > >> >Query "SELECT >> >AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM >> >AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=1" >> >execution time: 70 result set fetch time: >> >0 >> >Query "SELECT >> >AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM >> >AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=2" >> >execution time: 0 result set fetch time: >> >0 >> >Query "SELECT >> >AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM >> >AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=3" >> >execution time: 70 result set fetch time: >> >0 >> >Query "SELECT >> >AA_PRODUCT.NAME,AA_PRODUCT.PRODUCT_GROUP_ID FROM >> >AA_PRODUCT WHERE AA_PRODUCT.PRODUCT_ID=4" >> >execution time: 10 result set fetch time: >> >0 >> > >> >In some instances I would want to load the children >> >(i.e. a ProductGroup detail page) and other cases I >> >wouldn't want to spend time loading the children >> (i.e. >> >a ProductGroup search results page that didn't >> display >> >any Product info). So...my first question, is >> there a >> >way to specify lazy loading of a field at runtime? >> No, there isn't. Imho, it would be an interesting >> exercise to add such a feature, but I personally >> believe that the calling semantics of such a feature >> >> would be quite hard to specify. >> >> >In an effort to optimize, I turned the field "lazy" >> >attribute value from false to true in the >> ProductGroup >> >mapping, which resulted in just the first sql query >> >being issued...so far so good. However, after >> closing >> >the query via a database.close() call, and >> returning >> >the ProductGroup object to the presentation tier, I >> >got the following exception when trying to access >> the >> >ProductGroup's Products: >> > >> >java.lang.RuntimeException: Transaction is closed! >> > >> >>org.exolab.castor.persist.RelationCollection$IteratorImp.lazyLoad(RelationCollection.java:282) >> > >> >>org.exolab.castor.persist.RelationCollection$IteratorImp.next(RelationCollection.java:266) >> > >> >Which leads me to my second question: How are lazy >> >loaded collections properly used in a web app >> >environment? Am I supposed to leave the database >> >object open until the presentation tier is done >> with >> >the query. Am I supposed to loop through the >> search >> >results (effectively loading them) before returning >> >them to the presentation tier? >> > >> >Thanks, >> >Jon >> > >> > >> > >> >>----------------------------------------------------------- >> >> >If you wish to unsubscribe from this mailing, send >> mail to >> >[EMAIL PROTECTED] with a subject of: >> > unsubscribe castor-dev >> > >> > >> > >> > >> >> >> >> >----------------------------------------------------------- >> >> If you wish to unsubscribe from this mailing, send >> mail to >> [EMAIL PROTECTED] with a subject of: >> unsubscribe castor-dev > > > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
