• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

LAZY INITIALIZATION EXCEPTION

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

We are Working with JSF, Seam and EJB3. we are facing problems of Lazy Initialization.


As a Quick fix, changed collections/Sets to "EAGER". But, as the number of entites are more, We are getting Oracle Exception - ORA-01445 while opening any page.

Please let me know any solution for this, if any one knows.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This sort of sits on the border between something that should go in the ORM forum and something for JSF.

It's very important when designing an app to sit down and determine what your fetch sets are. That way you'll know what data deserves eager fetching and what data deserves lazy fetching and you won't consume resources fetching the wrong things at the wrong times.

One Easy Way Out for JSF is to install a hook into the ORM system that keeps the connection open all the way to the end of the request/response cycle. That way you can make everything be lazy-fetched and still access data safely. It's a very popular approach, since it makes it possible to "Git 'R Dun!" without actually knowing what you're doing and that's considered wonderful according to today's popular development paradigms, where fast and cheap are generally the only considerations and secure, efficient and reliable are given only token respect, if any.

On the other hand, resorting to this sort of kludge is not only lazy programming (as opposed to lazy fetching), it holds onto resources longer that strictly necessary. So it can have an impact on heavily-loaded systems. The alternative is do do the fetch set analysis and add extra service methods to expand on topics as needed. For example, my service method might return a collection of invoices. I might find it useful to have an additional service method to fetch details on an invoice (as opposed to discrete DAOs for invoices and invoice details). This detail fetch may be aware that certain tertiary data also needs to be fetched and take steps to ensure that that data is made accessible as well.

Sophisticated ORM systems also often permit the definition of "fetch groups". These can be used to eager-fetch items when you know you want specific sets of data fetched at the same time.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One workaround which we used when we were stuck with a bigger object graph... Invoking size() on a collections list which basically loads all the data as needed. So when you are trying to use the data, this trick can sort real big issues...
 
Hey, I'm supposed to be the guide! Wait up! No fair! You have the tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic