{"id":24513,"date":"2020-03-20T21:01:23","date_gmt":"2020-03-20T20:01:23","guid":{"rendered":"https:\/\/thorben-janssen.com\/?p=24513"},"modified":"2021-10-31T16:10:57","modified_gmt":"2021-10-31T15:10:57","slug":"lazyinitializationexception","status":"publish","type":"post","link":"https:\/\/thorben-janssen.com\/lazyinitializationexception\/","title":{"rendered":"LazyInitializationException – What it is and the best way to fix it"},"content":{"rendered":"\n

The LazyInitializationException <\/em>is one of the most common exceptions when working with Hibernate. There are a few easy ways to fix it. But unfortunately, you can also find lots of bad advice online. The proclaimed fixes often replace the exception with a hidden problem that will cause trouble in production. Some of them introduce performance issues, and others might create inconsistent results.<\/p>\n\n\n\n

In the following paragraphs, I will explain to you what the LazyInitializationException <\/em>is, which advice you should ignore, and how to fix the exception instead.<\/p>\n\n\n\n\n\n\n\n

When does Hibernate throw a LazyInitializationException<\/h2>\n\n\n\n

Hibernate throws the LazyInitializationException <\/em>when it needs to initialize a lazily fetched association to another entity without an active session context. That’s usually the case if you try to use an uninitialized association in your client application or web layer.<\/p>\n\n\n\n

Here you can see a test case with a simplified example.<\/p>\n\n\n\n

EntityManager em = emf.createEntityManager();\nem.getTransaction().begin();\n\nTypedQuery<Author> q = em.createQuery(\n\t\t"SELECT a FROM Author a",\n\t\tAuthor.class);\nList<Author> authors = q.getResultList();\nem.getTransaction().commit();\nem.close();\n\nfor (Author author : authors) {\n\tList<Book> books = author.getBooks();\n\tlog.info("... the next line will throw LazyInitializationException ...");\n\tbooks.size();\n}<\/pre>\n\n\n\n
The database query returns an Author <\/em>entity with a lazily fetched association to the books this author has written. Hibernate initializes the books <\/em>attributes with its own List<\/em> implementation, which handles the lazy loading. When you try to access an element in that List <\/em>or call a method that operates on its elements, Hibernate’s List <\/em>implementation recognizes that no active session is available and throws a LazyInitializationException<\/em>.<\/p>\n\n\n\n
How to NOT fix the LazyInitializationException<\/h2>\n\n\n\n
As I wrote at the beginning, you can find lots of bad advice on how to fix the LazyInitializationException<\/em>. Let me quickly explain which suggestions you should ignore.<\/p>\n\n\n\n
Don’t use FetchType.EAGER<\/h3>\n\n\n\n
Some developers suggest changing the FetchType<\/a> <\/em>of the association to EAGER<\/em>. This, of course, fixes the LazyInitializationException<\/em>, <\/em>but it introduces performance problems that will show up in production.<\/p>\n\n\n\n
When you set the FetchType <\/em>to EAGER<\/em>, Hibernate will always fetch the association, even if you don’t use it in your use case. That obviously causes an overhead that slows down your application. But it gets even worse if you don’t use the EntityManager<\/em>.find method and don’t reference the association in a JOIN FETCH<\/em> clause. Hibernate then executes an additional query to fetch the association. This often results in the n+1 select issue<\/a>, which is the most common cause of performance issues.<\/p>\n\n\n\n
So please, don’t use FetchType.EAGER<\/em>. As explained in various<\/a> articles<\/a> on this blog, you should always prefer FetchType.LAZY<\/em>.<\/p>\n\n\n\n
Avoid the Open Session in View anti-pattern<\/h3>\n\n\n\n
When using the Open Session in View anti-patter, you open and close the EntityManager <\/em>or Hibernate Session <\/em>in your view layer. You then call the service layer, which opens and commits a database transaction. Because the Session <\/em>is still open after the service layer returned the entity, the view layer can then initialize the lazily fetched association.<\/p>\n\n\n\n
But after the service layer committed the database transaction, there is no active transaction. Because of that, Hibernate executes each SQL statement triggered by the view layer in auto-commit mode. This increases the load on the database server because it has to handle an extra transaction for each SQL statement. At the end of each of these transactions, the database has to write the transaction log to the disc, which is an expensive operation.<\/p>\n\n\n\n
The increased pressure on your database isn’t the only downside of this anti-pattern. It can also produce inconsistent results because you are now using 2 or more independent transactions. As a result, the lazily fetched association might return different data than your service layer used to perform the business logic. Your view layer then presents both information together and it might seem like your application manages inconsistent data.<\/p>\n\n\n\n
Unfortunately, Spring Boot uses the Open Session in View anti-pattern by default. It only logs a warning message.<\/p>\n\n\n\n
2020-03-06 16:18:21.292  WARN 11552 --- [  restartedMain] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning<\/pre>\n\n\n\n
You can deactivate it by setting the spring.jpa.open-in-view<\/em> parameter in your application.properties<\/em> file to false<\/em>.<\/p>\n\n\n\n
Don’t use hibernate.enable_lazy_load_no_trans<\/h3>\n\n\n\n
Another suggestion you should avoid is to set the hibernate.enable_lazy_load_no_trans<\/em> configuration parameter in the persistence.xml<\/em> file to true. This parameter tells Hibernate to open a temporary Session <\/em>when no active Session <\/em>is available to initialize the lazily fetched association. This increases the number of used database connections, database transactions and the overall load on your database. <\/p>\n\n\n\n
OK, so what should you do instead?<\/p>\n\n\n\n
How to fix the LazyInitializationException<\/h2>\n\n\n\n
The right way to fix a LazyInitializationException <\/em>is to fetch all required associations within your service layer. The best option for that is to load the entity with all required associations in one query. Or you can use a DTO projection, which doesn’t support lazy loading and needs to be fully initialized before you return it to the client.<\/p>\n\n\n\n
Let’s take a closer look at the different options to initialize lazily fetched association and at the best way to use DTO projections.<\/p>\n\n\n\n
Initializing associations with a LEFT JOIN FETCH clause<\/h3>\n\n\n\n
The easiest way to load an entity with all required associations is to perform a JPQL or Criteria Query with one or more LEFT JOIN FETCH <\/em>clauses. That tells Hibernate to not only fetch the entity referenced in the projection but also to fetch all associated entities referenced in the LEFT JOIN FETCH<\/em> clause.<\/p>\n\n\n\n
Here you can see a simple example of such a query. <\/p>\n\n\n\n
EntityManager em = emf.createEntityManager();\nem.getTransaction().begin();\n\nTypedQuery<Author> q = em.createQuery("SELECT a FROM Author a LEFT JOIN FETCH a.books", Author.class);\nList<Author> authors = q.getResultList();\n\nem.getTransaction().commit();\nem.close();\n\nfor (Author a : authors) {\n\tlog.info(a.getName() + " wrote the books " \n\t\t+ a.getBooks().stream().map(b -> b.getTitle()).collect(Collectors.joining(", "))\n\t);\n}<\/pre>\n\n\n\n
The query selects Author <\/em>entities, and the LEFT JOIN FETCH clause tells Hibernate to also fetch the associated Book <\/em>entities. As you can see in the generated SQL statement, Hibernate not only joins the 2 corresponding tables in the FROM clause, it also added all columns mapped by the Book<\/em> entity to the SELECT clause. <\/p>\n\n\n\n
select\n\tauthor0_.id as id1_0_0_,\n\tbooks1_.id as id1_2_1_,\n\tauthor0_.name as name2_0_0_,\n\tauthor0_.version as version3_0_0_,\n\tbooks1_.author_id as author_i7_2_1_,\n\tbooks1_.authorEager_id as authorEa8_2_1_,\n\tbooks1_.publisher as publishe2_2_1_,\n\tbooks1_.publishingDate as publishi3_2_1_,\n\tbooks1_.sells as sells4_2_1_,\n\tbooks1_.title as title5_2_1_,\n\tbooks1_.version as version6_2_1_,\n\tbooks1_.author_id as author_i7_2_0__,\n\tbooks1_.id as id1_2_0__ \nfrom\n\tAuthor author0_ \nleft outer join\n\tBook books1_ \n\t\ton author0_.id=books1_.author_id<\/pre>\n\n\n\n
As you can see in the log messages, the query returned an Author <\/em>entity with an initialized books <\/em>association.<\/p>\n\n\n\n
16:56:23,169 INFO  [org.thoughtsonjava.lazyintitializationexception.TestLazyInitializationException] - Thorben Janssen wrote the books Hibernate Tips - More than 70 solutions to common Hibernate problems<\/pre>\n\n\n\n
Use a @NamedEntityGraph<\/em> to initialize an association<\/h3>\n\n\n\n
You can do the same using a @NamedEntityGraph<\/em>. The main difference is that the definition of the graph is independent of the query. That enables you to use the same query with different graphs or to use the same graph with various queries.<\/p>\n\n\n\n
I explained @NamedEntityGraphs<\/em> in great detail in a previous article<\/a>. So, I keep the explanation short. You can define the graph by annotating one of your entity classes with a @NamedEntityGraph<\/em> annotation. Within this annotation, you can provide multiple @NamedAttributeNode<\/em> annotations to specify the attributes that Hibernate shall fetch.<\/p>\n\n\n\n
@NamedEntityGraph(\n    name = "graph.authorBooks",\n    attributeNodes = @NamedAttributeNode("books")\n)\n@Entity\npublic class Author { ... }<\/pre>\n\n\n\n
To use this graph, you first need to get a reference to it from your EntityManager<\/em>. In the next step, you can set it as a hint on your query.<\/p>\n\n\n\n
EntityManager em = emf.createEntityManager();\nem.getTransaction().begin();\n\nEntityGraph<?> entityGraph = em.createEntityGraph("graph.authorBooks");\nTypedQuery<Author> q = em.createQuery("SELECT a FROM Author a", Author.class)\n\t\t.setHint("javax.persistence.fetchgraph", entityGraph);\nList<Author> authors = q.getResultList();\n\nem.getTransaction().commit();\nem.close();\n\nfor (Author a : authors) {\n\tlog.info(a.getName() + " wrote the books " \n\t\t+ a.getBooks().stream().map(b -> b.getTitle()).collect(Collectors.joining(", "))\n\t);\n}<\/pre>\n\n\n\n
If you look at the generated SQL statement, you can see that there is no difference between a LEFT JOIN FETCH<\/em> clause and a @NamedEntityGraph<\/em>. Both approaches result in a query that selects all columns mapped by the Author <\/em>and the Book <\/em>entity and return Author <\/em>entities with an initialized books <\/em>association.<\/p>\n\n\n\n
select\n\tauthor0_.id as id1_0_0_,\n\tbooks1_.id as id1_2_1_,\n\tauthor0_.name as name2_0_0_,\n\tauthor0_.version as version3_0_0_,\n\tbooks1_.author_id as author_i7_2_1_,\n\tbooks1_.authorEager_id as authorEa8_2_1_,\n\tbooks1_.publisher as publishe2_2_1_,\n\tbooks1_.publishingDate as publishi3_2_1_,\n\tbooks1_.sells as sells4_2_1_,\n\tbooks1_.title as title5_2_1_,\n\tbooks1_.version as version6_2_1_,\n\tbooks1_.author_id as author_i7_2_0__,\n\tbooks1_.id as id1_2_0__ \nfrom\n\tAuthor author0_ \nleft outer join\n\tBook books1_ \n\t\ton author0_.id=books1_.author_id<\/pre>\n\n\n\n
EntityGraph to initialize an association<\/h3>\n\n\n\n
The EntityGraph <\/em>API provides you the same functionality as the @NamedEntityGraph<\/em> annotation. The only difference is that you use a Java API instead of annotations to define the graph. That enables you to adjust the graph definition dynamically.<\/p>\n\n\n\n
As you can see in the code snippet, the API-based definition of the graph follows the same concepts as the annotation-based definition. You first create the graph by calling the createEntityGraph<\/em> method. In the next step, you can add multiple attributes nodes and subgraphs to the graph. I explain all of that in great detail in JPA Entity Graphs: How to Dynamically Define and Use an EntityGraph<\/a>.<\/p>\n\n\n\n
EntityManager em = emf.createEntityManager();\nem.getTransaction().begin();\n\nEntityGraph<Author> entityGraph = em.createEntityGraph(Author.class);\nentityGraph.addAttributeNodes("books");\nTypedQuery<Author> q = em.createQuery("SELECT a FROM Author a", Author.class)\n\t\t.setHint("javax.persistence.fetchgraph", entityGraph);\nList<Author> authors = q.getResultList();\n\nem.getTransaction().commit();\nem.close();\n\nfor (Author a : authors) {\n\tlog.info(a.getName() + " wrote the books " \n\t\t+ a.getBooks().stream().map(b -> b.getTitle()).collect(Collectors.joining(", "))\n\t);\n}<\/pre>\n\n\n\n
After you defined the graph, you can use it in the same way as a @NamedEntityGraph<\/em>, and Hibernate generates an identical query for both of them.<\/p>\n\n\n\n
select\n\tauthor0_.id as id1_0_0_,\n\tbooks1_.id as id1_2_1_,\n\tauthor0_.name as name2_0_0_,\n\tauthor0_.version as version3_0_0_,\n\tbooks1_.author_id as author_i7_2_1_,\n\tbooks1_.authorEager_id as authorEa8_2_1_,\n\tbooks1_.publisher as publishe2_2_1_,\n\tbooks1_.publishingDate as publishi3_2_1_,\n\tbooks1_.sells as sells4_2_1_,\n\tbooks1_.title as title5_2_1_,\n\tbooks1_.version as version6_2_1_,\n\tbooks1_.author_id as author_i7_2_0__,\n\tbooks1_.id as id1_2_0__ \nfrom\n\tAuthor author0_ \nleft outer join\n\tBook books1_ \n\t\ton author0_.id=books1_.author_id<\/pre>\n\n\n\n
Using a DTO projection<\/h3>\n\n\n\n
Fetching all required associations when you load the entity fixes the LazyInitializationException<\/em>. But there is an alternative that’s an even better fit for all read operations. As I showed in a previous article, DTO projections provide significantly better performance<\/a> if you don’t want to change the retrieved information.<\/p>\n\n\n\n
In these situations, you can use a constructor expression to tell Hibernate to instantiate a DTO object for each record in the result set.<\/p>\n\n\n\n
EntityManager em = emf.createEntityManager();\nem.getTransaction().begin();\n\nTypedQuery<AuthorDto> q = em.createQuery(\n\t\t"SELECT new org.thoughtsonjava.lazyintitializationexception.dto.AuthorDto(a.name,b.title) FROM Author a JOIN a.books b",\n\t\tAuthorDto.class);\nList<AuthorDto> authors = q.getResultList();\n\nem.getTransaction().commit();\nem.close();\n\nfor (AuthorDto author : authors) {\n\tlog.info(author.getName() + " wrote the book " + author.getBookTitle());\n}<\/pre>\n\n\n\n
Hibernate then generates an SQL statement that only selects the columns that are mapped by the attributes that you reference in the constructor call. This often reduces the number of selected columns and improves the performance even further.<\/p>\n\n\n\n
select\n\tauthor0_.name as col_0_0_,\n\tbooks1_.title as col_1_0_ \nfrom\n\tAuthor author0_ \ninner join\n\tBook books1_ \n\t\ton author0_.id=books1_.author_id<\/pre>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
If you have used Hibernate for a while, you probably had to fix at least one LazyInitializationException<\/em>. It’s one of the most common ones when working with Hibernate.<\/p>\n\n\n\n
As I explained in this article, you can find lots of advice online on how to fix this exception. But a lot of these suggestions only replace the exception with problems that will show up in production.<\/p>\n\n\n\n
There are only 2 good solutions to this problem:<\/p>\n\n\n\n
  1. You initialize all required associations when you load the entity using a LEFT JOIN FETCH <\/em>clause or a @NamedEntityGraph<\/em> or the EntityGraph <\/em>API.<\/li>
  2. You use a DTO projection instead of entities. DTOs don’t support lazy loading, and you need to fetch all required information within your service layer.<\/li><\/ol>\n","protected":false},"excerpt":{"rendered":"
    The LazyInitializationException is one of the most common exceptions when working with Hibernate. There are a few easy ways to fix it. But unfortunately, you can also find lots of bad advice online. The proclaimed fixes often replace the exception with a hidden problem that will cause trouble in production. Some of them introduce performance…<\/p>\n","protected":false},"author":14418,"featured_media":24690,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"video","meta":{"_kad_blocks_custom_css":"","_kad_blocks_head_custom_js":"","_kad_blocks_body_custom_js":"","_kad_blocks_footer_custom_js":"","_kadence_starter_templates_imported_post":false,"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[9,19],"tags":[69,117,64,33],"class_list":["post-24513","post","type-post","status-publish","format-video","has-post-thumbnail","hentry","category-hibernate","category-hibernate-performance","tag-association-mapping","tag-associationmappingpage-fetching","tag-best-practice","tag-query","post_format-post-format-video"],"taxonomy_info":{"category":[{"value":9,"label":"Hibernate"},{"value":19,"label":"Hibernate Performance"}],"post_tag":[{"value":69,"label":"Association Mapping"},{"value":117,"label":"AssociationMappingPage-Fetching"},{"value":64,"label":"Best Practice"},{"value":33,"label":"Query"}]},"featured_image_src_large":["https:\/\/thorben-janssen.com\/wp-content\/uploads\/2020\/03\/LazyInitializationException-What-it-is-how-to-fix-it-2.jpg",810,450,false],"author_info":{"display_name":"Thorben Janssen","author_link":"https:\/\/thorben-janssen.com\/author\/thorben-janssen\/"},"comment_info":10,"category_info":[{"term_id":9,"name":"Hibernate","slug":"hibernate","term_group":0,"term_taxonomy_id":9,"taxonomy":"category","description":"","parent":0,"count":28,"filter":"raw","cat_ID":9,"category_count":28,"category_description":"","cat_name":"Hibernate","category_nicename":"hibernate","category_parent":0},{"term_id":19,"name":"Hibernate Performance","slug":"hibernate-performance","term_group":0,"term_taxonomy_id":19,"taxonomy":"category","description":"","parent":9,"count":41,"filter":"raw","cat_ID":19,"category_count":41,"category_description":"","cat_name":"Hibernate Performance","category_nicename":"hibernate-performance","category_parent":9}],"tag_info":[{"term_id":69,"name":"Association Mapping","slug":"association-mapping","term_group":0,"term_taxonomy_id":69,"taxonomy":"post_tag","description":"","parent":0,"count":44,"filter":"raw"},{"term_id":117,"name":"AssociationMappingPage-Fetching","slug":"associationmappingpage-fetching","term_group":0,"term_taxonomy_id":117,"taxonomy":"post_tag","description":"","parent":0,"count":6,"filter":"raw"},{"term_id":64,"name":"Best Practice","slug":"best-practice","term_group":0,"term_taxonomy_id":64,"taxonomy":"post_tag","description":"","parent":0,"count":30,"filter":"raw"},{"term_id":33,"name":"Query","slug":"query","term_group":0,"term_taxonomy_id":33,"taxonomy":"post_tag","description":"","parent":0,"count":103,"filter":"raw"}],"_links":{"self":[{"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/posts\/24513","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/users\/14418"}],"replies":[{"embeddable":true,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/comments?post=24513"}],"version-history":[{"count":3,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/posts\/24513\/revisions"}],"predecessor-version":[{"id":41022,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/posts\/24513\/revisions\/41022"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/media\/24690"}],"wp:attachment":[{"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/media?parent=24513"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/categories?post=24513"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thorben-janssen.com\/wp-json\/wp\/v2\/tags?post=24513"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}