Announcement Announcement Module
Collapse
No announcement yet.
LazyInitializationException in DAO layer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • LazyInitializationException in DAO layer

    Hi,

    I don't know why I would get this error in my dao method when the Spring injected EntityManager (em) context is still available. Why would the Hibernate session be closed when em is not?

    If I don't use Spring, and I get the em from EntityManagerFactory, then my dao would work fine.

    Code:
         Product p1 = em.find(Product.class, id);       
           List<Product> products = p1.getTechnologies().get(0).getProducts();
           for (Product p: products) {
               System.out.println("productName=" + p.getProduct());
           }
    
    11:59:27,593 ERROR LazyInitializationException: failed to lazily initialize a collection of role: model.Product.technologies, no session or session was closed

    I also noticed that Spring injected em is not per ThreadLocal, meaning the injected em in catalogDao and productDao within the same thread is not the same. If I want to share the same persistence context, then I need to pass the em between the two daos. Is that right?

  • #2
    If you define a transaction at a higher level e.g. the service layer then this is all handled for you. Have a read of the reference manual.
    http://www.springframework.org/docs/...ansaction.html

    Comment


    • #3
      Hi,

      I am running into the same issue.

      I have defined the transaction two levels higher (business level) and that works fine. But if I want to run (unit)tests I want to run the code at dao/service level. But since there is no transaction defined at that level the code fails with the LazyException.
      Now I don't want to define a transaction for each test class in my applciationContext (to much work since there will be lots of test classes) and I also don't want to define a transaction at low level in my code just for testing purposes. So how to solve this? Is there an nice solution for this, since I guess I am not the first one with this problem.

      I am using Hiberate 3.2 (with Annotations) and Spring 1.2.3.

      Comment


      • #4
        if you define TXs on each level as REQUIRED, then the top-most wins.
        That means, that if you set your DAO-methods as TX-able, then it won't break the TX-management, when they are called from the business-layer, but in the same time you can call them from any other place without worrying about lazy-init problems.

        Comment


        • #5
          Thx for your quick response. I have found another solution for my specific problem. And like always: once you have seen it, you ask yourself why didn't I come up with this right away. But anyhow, since we are using TestNG for our tests I can create/open a transaction before my test, run my test and then close the transaction programmaticaly. This way I am sure my whole test fits into one transaction (and session).
          I have done a quick test with this approach and it looks good.

          Comment


          • #6
            If you have a look in the Spring testing support classes, that's what they do anyway.
            http://www.springframework.org/docs/...tml#testing-tx

            Comment


            • #7
              With the AbstractTransactionalSpringContextTests api, the unit tests can also be made transactional. It creates a transaction for each test method and closes it or basically rollsback at the end so no test data is persistent. Just my input on your testing scenario.

              Comment


              • #8
                Originally posted by neerajn View Post
                With the AbstractTransactionalSpringContextTests api, the unit tests can also be made transactional. It creates a transaction for each test method and closes it or basically rollsback at the end so no test data is persistent. Just my input on your testing scenario.
                That's the great thing about the transactional support classes. The ability for it all to be rolled back for you is great!

                Comment

                Working...
                X