aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes What is the official solution for Lazy problem? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "What is the official solution for Lazy problem?" Watch "What is the official solution for Lazy problem?" New topic
Author

What is the official solution for Lazy problem?

Davi Shibayama
Greenhorn

Joined: Mar 12, 2008
Posts: 1
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.
    Marc Peabody
    pie sneak
    Sheriff

    Joined: Feb 05, 2003
    Posts: 4727

    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.


    A good workman is known by his tools.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: What is the official solution for Lazy problem?
     
    Similar Threads
    Some questions regarding part II
    Multiple sessions paging result sets...
    Simple pattern
    Wrote SCEA Beta Test Exam Today - Feedback on the Sun Certified Architect Exam Part 1
    Lazy loading exception in presentation layer, what's the nicest way to avoid them?