Fixing HibernateException: Illegal Attempt to Associate a Collection With Two Open Sessions

1. Overview

In this brief tutorial, we’ll highlight how to fix the HibernateException: Illegal attempt to associate a collection with two open sessions.

We’ll start by examining the root cause of the exception. Then, through practical examples, we’ll demonstrate how to reproduce it and, most importantly, how to fix it.

2. Understanding HibernateException

Typically, the “HibernateException: Illegal attempt to associate a collection with two open sessions”, as the name implies, occurs when a lazily loaded collection, mapped with @OneToMany, is modified outside of its original Hibernate session.

Hibernate tightly couples collections to the session that loads them, so attempting to access or modify such a collection in another session causes a conflict. For instance, this happens when we use the now-deprecated update() method on a detached entity, something that Hibernate no longer recommends.

Understanding the meaning of this exception is crucial to properly handle session boundaries and lazy-loading behavior in a Hibernate-based application. So, let’s go down the rabbit hole and see how to reproduce and fix HibernateException using real-world examples.

3. Practical Example

First, let’s consider the Author JPA entity class:

@Entity
public class Author {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL)
    private List<Book> books;

    public Author(String name) {
        this.name = name;
        this.books = new ArrayList<>();
    }

    // empty constructor, standard getters and setters

}

Simply put, each author has a unique identifier and a name. The @Entity annotation designates the Author class as a JPA entity, while @Id marks the primary key. The @OneToMany annotation describes the association between an author and their books.

Next, we’ll define the Book entity class:

@Entity
public class Book {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    private String title;

    @ManyToOne
    private Author author;

    public Book(String title) {
        this.title = title;
    }

    // empty constructor, standard getters and setters

}

Here, @ManyToOne denotes that the Book class shares a many-to-one relationship with the Author class. This means that a given author may have many books.

Now, let’s reproduce HibernateException using a test case:

@Test
void givenAnEntity_whenChangesSpanMultipleHibernateSessions_thenThoseChangesCanNotBeUpdated() {
    assertThatThrownBy(() -> {
        try (Session session1 = HibernateUtil.getSessionFactory()
            .openSession(); 
            Session session2 = HibernateUtil.getSessionFactory()
              .openSession()) {
            session1.beginTransaction();

            Author author = new Author("Leo Tolstoy");
            session1.persist(author);

            session1.getTransaction()
              .commit();

            session2.beginTransaction();
            author.getBooks()
              .add(new Book("War and Peace"));
            session2.update(author); // oops!
            session2.getTransaction()
              .commit();
        }
    }).isInstanceOf(HibernateException.class)
      .hasMessageContaining("Illegal attempt to associate a collection with two open sessions");
}

In this test case, the author instance is loaded in session1, but then passed to session2, where its book list was updated. Using update() leads Hibernate to throw the exception because the book collection is still associated with the original session (session1).

Please note that the main cause of the issue is not just improper session handling. It’s the use of the deprecated update() method, which assumes that the entity is originally loaded in the current session.

4. Solutions

The most straightforward solution is to use the merge() method, which safely reattaches a detached entity (and its collections) to a new session, instead of the deprecated update() method:

@Test
void givenAnEntity_whenChangesSpanMultipleHibernateSessions_thenThoseChangesCanBeMerged() {
    try (Session session1 = HibernateUtil.getSessionFactory()
        .openSession();
        Session session2 = HibernateUtil.getSessionFactory()
          .openSession()) {
        session1.beginTransaction();

        Author author = // populate
        session1.persist(author);

        session1.getTransaction()
          .commit();

        session2.beginTransaction();
        Book newBook = // populate
        author.getBooks()
          .add(newBook);
        session2.merge(author); // merge instead of update
        session2.getTransaction()
          .commit();
    }
}

In a nutshell, the merge() method re-associates the detached author, the one that was loaded in session1 with the new session session2.

Simply put, it copies the state of the detached instance into a new managed instance in the current session. That way, the new instance and its collection are associated with only the current session.

If we don’t want to use the merge() method, we can simply keep the entire operation within a single session. That way, we prevent the book collection from being associated with multiple sessions simultaneously:

@Test
void givenAnEntity_whenChangesUseTheSameHibernateSession_thenThoseChangesCanBeUpdated() {
    try (Session session1 = HibernateUtil.getSessionFactory()
        .openSession()) {
        session1.beginTransaction();

        Author author = // populate as before
        session1.persist(author);

        Book newBook = // populate as before
        author.getBooks()
          .add(newBook);
        session1.update(author); // use the same session

        session1.getTransaction()
          .commit();
    }
}

As expected, the new test case runs successfully, confirming that our fix effectively prevents HibernateException.

5. Conclusion

In this short article, we explored the main cause behind HibernateException: Illegal attempt to associate a collection with two open sessions. Along the way, we demonstrated how to reproduce the exception in practice and provided a clear solution to solve it.