• 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

What is the official solution for Lazy problem?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm trying to build a webapp with the architecture similar to that example app in the Hibernate site (Caveat Emptor, JPA/EJB3 version), I mean, JSF for the view, controllers as EJB Session Beans and a DAO layer also implemented as Stateless EJB.
In that application, I'm using container-managed entity manager, through dependency injection via annotations.
In addition, I have the following requirements/restrictions:
  • I cannot/do not want to use the Open Session in View pattern, or anything similar, like JSF phase listeners.
  • I cannot aggregate any kind of framework that has built-in solution to that Lazy problem, like Spring or Seam, to my project. Only default JavaEE products/specifications.
  • In some use cases of that webapp, I will have long running conversation, with several page requests inside a single business process, that should be commited only in the last page, moroless like wizards.
  • All parent-child/one-to-many relationship MUST be mapped LAZY, I mean, FetchType.EAGER or queries using FETCH JOIN is NOT an option.


  • So, considering all this things above, my question is: What is the solution to avoid LazyInitializationException in such a scenario?

    If my question or situation is not clear, I can put some sample code here, or I can try to explain it better.

    Sorry for my weird english.

    I really appreciate any help.

    Davi.
     
    pie sneak
    Posts: 4727
    Mac VI Editor Ruby
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I mean, JSF for the view, controllers as EJB Session Beans and a DAO layer also implemented as Stateless EJB.
    Typically your Stateless Session Beans would act as a Service or Session Facade. It's more likely that your JSF backing beans are acting as the controller. Your coarse-grained CRUD operations may be better off in a separate DAO class outside of the Stateless Session Bean. The primary value of the session EJB is to manage transactions, so keeping a transactional focus of the session EJB class(es) should help out.

    In that application, I'm using container-managed entity manager, through dependency injection via annotations.
    So... you're also using Spring or Guice for the dependency injection? If you're using Spring you might as well take advantage of its awesome HibernateDAOSupport for your DAO classes and make some Service POJOs with transaction management to replace the session EJBs.

    I cannot/do not want to use the Open Session in View pattern, or anything similar, like JSF phase listeners.
    I don't blame you. Something about the Open Session in View "pattern" never settled right with me.

    I cannot aggregate any kind of framework that has built-in solution to that Lazy problem, like Spring or Seam, to my project. Only default JavaEE products/specifications.
    Oh, so you're not using Spring. You know, Hibernate is not a "default" JavaEE product either.

    In some use cases of that webapp, I will have long running conversation, with several page requests inside a single business process, that should be commited only in the last page, moroless like wizards.
    In most cases you might as well build up all that data in your JSF backing beans until you're finally ready to submit the transaction.

    All parent-child/one-to-many relationship MUST be mapped LAZY, I mean, FetchType.EAGER or queries using FETCH JOIN is NOT an option.
    OK.

    What is the solution to avoid LazyInitializationException in such a scenario?
    Your back end components should retrieve whatever data your front end needs. You can make extra DAO methods that use HQL to fetch however much of the object structure your front end needs. It's not terribly difficult, but it does require a bit more programming effort.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic