Detached entity passed to persist ошибка

Detached entity passed to persist exception or its variations like spring detached entity passed to persist can come up in various situations, among which persisting an entity that is already present in your database ranks at the top.

The term “detached entity” in the exception statement refers to an entity already residing in the database because you have persisted the same earlier. Now, this post will state the different causes of the given exception and help you normalize the problematic situations to make your code work again.

After reading this article, you’ll be aware of the next step that’ll eliminate the same exception permanently.

What Invites the Detached Entity Passed To Persist Exception?

Your attempt to persist an already persisted entity can invite the spring data jpa detached entity passed to persist exception to your system. Plus, assigning a value to an auto-generated column, having setters while persisting an entity, or passing a child collection to the equals() function also causes this error.

– You Are Trying To Persist an Already Persisted Entity

Trying to persist an already persisted entity can make the detached entity passed to persist test exception pop up on your screen. The reason is simple. You can not add an already existing entity to the database. However, you can always update it or add more details to it.

For example, you have created the student and teacher entities. The given entities have many-to-one relationships between them. The idea is based on a real-world concept pointing toward a single teacher teaching many students, and every student is taught by one teacher. Next, you have created a teacher object, assigned multiple students to it, and persisted the same object.

Until this step, everything worked fine. Later, you tried to create an object of the student entity, which has a many-to-one relationship with the teacher entity.

But the moment you try to persist the student object, you’ll get the detached entity passed to persist many-to-one exception disallowing the student object to persist. It is because persisting the student object will also persist the already persisted teacher object, which is not acceptable and impossible.

The reference code showing the entities has been attached below.

– You Are Having a Setter While Persisting an Entity

You aren’t allowed to have setters for an entity if you plan to persist the same. If you try to set a value for an entity, such as an id, while persisting it, you’ll receive the invaliddataaccessapiusageexception: detached entity passed to persist exception. In short, you can’t set values and persist an entity simultaneously.

For example, you have created an id setter for your employee entity. Now, you want to persist the given entity. Here, the setter will come in the way, pose a hurdle in persisting the employee entity, and result in the same exception.

– You Are Setting an ID for an Entity While It’s Auto-generated

Setting an id or primary key manually while you have switched on its auto-generation setting will bring you closer to the detached entity passed to persist entitymanager exception. It is because the columns with auto-generation settings do not require you to pass values to them.

Imagine having an id column for the books entity in the database. You have specified GenerationType.AUTO for the ID column. Now, if you try to set an id while creating a books object. You’ll end up receiving the stated exception.

The code snippet aligning with the above example is attached here.

– Your equals() Method Has a Child Collection

Passing a child collection to the equals() method will make hibernate assume that every element specified for the child collection is a new object that needs to be persisted instead of an updated value for the existing one. This misassumption might result in the same exception.

Think about it this way. You have an organization entity as a parent entity and an employee entity as a child entity. Now, if you try to run the equals() function with the employee collection, you’ll see the given exception on your screen.

The following block of code depicts the same scenario.

How To Save Yourself from the Detached Entity Passed To Persist Exception?

You can save yourself from the detached entity passed to persist exception by merging the entity that is already persisted, not specifying cascading with the child entity, or removing the setters while persisting an entity. Also, passing null to the auto-generated column can fix the issue.

– Choose Merge Over Persist or All

If the cause of the issue is persisting an already persisted entity, use CascadeType.MERGE instead of CascadeType.PERSIST or CascadeType.ALL with @ManyToOne to make things work for you. It means you should merge the persisted entity instead of persisting it again.

Talking about the example entities discussed above, you should replace CascadeType.ALL following @ManyToOne in the student entity with CascadeType.MERGE. It will ensure that the teacher entity is merged when persisting a student object. Consequently, the given exception will leave your screen too. Here is how the altered student entity should look.

– Avoid Specifying Cascading With the Child Entity

If you don’t want to use merge cascading with your child entity, then you might like to skip the cascading type. It will ensure that no action in the database affects the parent entity, which is mostly persisted already. Eventually, you’ll never receive the above exception on your screen.

So, you can alter the student entity as shown below.

– Remove the Setters

It would be best to remove any related setters while persisting an entity to get rid of the detached entity passed to persist panache exception. This way, the setters won’t interrupt the process, and your desired operation will be carried out perfectly. For the previous example, you can remove the id setter to settle things.

Deleting the setters is one of the simplest solutions, which will work like magic to eliminate the exception.

– Don’t Set the ID When It’s Not Required

If your id or primary key column is auto-generated, you should not pass an id while creating an object. You can specify null instead of an actual id to let the auto-generated value fit in and remove the said exception from your system.

Considering the Book entity example again, it would be best to create the object like Book book1 = new Book(null, “myBook”, “Anonymous”). Eventually, null will be replaced with an auto-generated id, and the book1 object will be created successfully with a valid id.

– Never Pass a Child Collection To the equals() Method

You should never pass a child collection to the equals() method to avoid hibernate make any misassumptions regarding the given collection. Once everything is clear to hibernate, the exception will disappear from your system. However, please remember that this solution is applied only in relevant cases.

Joining the thread with the previous example, you should remove the coding statement that calls the equals() function with the employee collection. It will help remove the said exception.

FAQ

1. How Can You Make a Detached Entity Persistent Again?

You can make a detached entity persistent again by using the update method of the session. The update method will force an update operation to be executed for the passed object. As the object is originally detached, Hibernate adds this object to the persistence context to make it persistent.

2. How Would You Differentiate Between Persist and Merge?

The difference between persist and merge is that persist should be called only on new entities, while the merge is used to reattach the detached entities. Contrary to the above situations, using merge instead of persist will cause a redundant SQL statement while using the assigned generator.

3. How Is save() Different from persist() in Hibernate?

The save() method is different from the persist() method in hibernate in a way that the save() method lets you assign the identifier value immediately. However, the persist() method fails to confirm the assignment of an identifier value to its persistent state instantly.

4. What Are the Transient and Persistent Objects?

The transient objects are the ones that haven’t been saved yet. It means all of the newly created entities are transient until you persist them. On the other hand, the persistent objects are the ones that have been saved to the database. Entities received from the repository are persistent objects.

5. Which Methods Should You Call To Make the Objects Persistent?

There are a variety of methods you can call to send the objects to the persistent state. The common methods include session.save(e), session.update(e), session.persist(e), session.lock(e), session.saveOrUpdate(e), and session.merge(e). You can execute the one that fits to your need.

Conclusion

The PersistentObjectException: detached entity passed to persist can result from persisting an already persistent entity or setting values for its auto-generated columns. In rare cases, the equals() function with a child collection as an argument can be problematic and result in the said exception. Here you go with a list of solutions extracted from the above post that’ll help you fix the given exception instantly.

• Merge the persisted entity instead of persisting it again to resolve the exception.
• Don’t specify any cascading type with the child entity to stay away from the exception.
• Never provide a value for a column that’ll have its values auto-generated to avoid confusion and, eventually, the exception.
• Ensure to have zero setters while persisting an entity to avoid the said exception.
• Don’t pass a child collection to the equals() function to push away the same exception.

Lastly, remember that the more you know about the dos and don’ts of working with the entities and persisting them, the fewer times you’ll encounter the given exception.

When doing an EntityManager.persist(myEntity), the entity is persisted only if its current state is «transient» (i.e. not yet persisted). We’ve got some problems while persisting objects for which Hibernate could not determine they are transient, so are sharing our experience here.

Software used:

• Hibernate 3.3.1.GA
• Webshpere 6.1.0.13 (JTA transactions)
• Seam 2.0.0.GA

Lets define the following entity:

Code:

To persist, we would use the following code:

Code:

MyEntity myEntity = new MyEntity();
myEntity.setId(1);
myEntity.setDescription(«fooBar»);
entityManager.persist(myEntity);

Now, lets modify the entity identifier (key) mapping to make it generated by a custom IdentifierGenerator (an Hibernate interface implemented by my.package.MyIdentifierGenerator):

Code:

The identifier generator is something like:

Code:

public class MyIdentifierGenerator implements IdentifierGenerator {
  public Serializable generate(SessionImplementor si, Object entity) {
    // WARNING: pseudo-Java code
    MyEntity myEntity = (MyEntity)entity;
    if (myEntity.getId()>0) {
      // the identifier has been set manually => use it
      return myEntity.getId();
    } else {
      // the identifier is not provided => generate it
      return getMyNextKey();
    }
  }
}

The code is now:

Code:

MyEntity myEntity = new MyEntity();
//myEntity.setId(1); // do not set the identifier as it is set by the my.package.MyIdentifierGenerator
myEntity.setDescription(«fooBar»);
entityManager.persist(myEntity);

However, if we want to force the key (identifier) to a specific value, i.e. to bypassing the custom IdentifierGenerator (which return the current object key or create a new one if the key does not exist), the code raises a PersistentObjectException:

Code:

MyEntity myEntity = new MyEntity();
myEntity.setId(1); // bypass the custom IdentifierGenerator and set an identifier not yet in the database
myEntity.setDescription(«fooBar»);
entityManager.persist(myEntity); // raise a PersistentObjectException

The exception raised is :

Code:

org.hibernate.PersistentObjectException: detached entity passed to persist: my.package.MyEntity
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:102)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)

Firstly, the problem is that the exception message should be more something like «cannot persist entity with identifier set manually AND via IdentifierGenerator». This would make debugging much easier.

Secondly, the exception should not occur because the object does not exist in the database with the given identifier.

The problem comes from the DefaultPersistEventListener.onPersist() method, which calls the parent AbstractSaveEventListener.getEntityState(), which return the entity state amongst the following: PERSISTENT, DELETED, TRANSIENT, DETACHED.
If not PERSISTENT, DELETED or TRANSIENT, the state is defaulted to DETACHED, which makes the exception to be raised. The two first states are checked using very simple tests and the TRANSIENT state is computed by the call to ForeignKeys.isTransient(), which tests the following operations:

1. let the Interceptor decide if the entity is transient
2. let the EntityPersister decide if the entity is transient
3. ask the database to determine if the instance exists (i.e. not transient) or not (i.e. transient)

In case presented above, the «not TRANSIENT» decision is made by the EntityPersister.isTransient() method. For the simple test case here (no version, no cache, identifier provided), the EntityPersister determine the transient state by comparing the identifier with the default unsavedValue (the identifier value for a not-yet-persisted entity): if they are the same, the entity is transient. In our test case above, this is obviously not the case because the default identifier value is 0 and the identifier set is 1.

The code review above allowed to find the following workaround:

Code:

Now, the exception is no more raised and the entity is persisted into the database with the id=1.

Note: the whole process should probably be included in a critical section using a synchronized block on the IdentifierProperty «ip».

IMHO, the ForeignKeys.isTransient() method should be improved to consider the fact that EntityPersister.isTransient() did not look into the database to determine that the object is not transient:

Code:

While this concept is useful for a persist operation, it may imply a lot more database lookup if the isTransient() method is used for other operations (e.g. for update, I did not check). Note that the workaround has the advantage to avoid the database lookup.

Hello,

if i use the Repository directly to update an Entity it’s works. But if the Repository a Depency inside a Controller i always get the following Error:
Unexpected error occurred: org.hibernate.PersistentObjectException: detached entity passed to persist: example.domain.Pet

I extend the given Example (example-jpa) with the PetRepository. I create a update method inside the Controller:

@Put("/{petId}")`
    HttpStatus update(@QueryValue("petId") Long petId, Pet pet) {
        Optional<Pet> result = petRepository.findById(petId);
        if (result.isPresent()) {
            Pet current = result.get();
            current.setName(pet.getName());
            petRepository.persist(current);

            return HttpStatus.CREATED;
        }

        return HttpStatus.NOT_FOUND;
    }

I added the method as described in the documentation:
Pet persist(Pet entity);

And create a Test for the PUT endpoint:

@MicronautTest
public class PetUpdateControllerTest {

    @Inject
    @Client("/")
    RxHttpClient client;

    @Test
    void test() {
        Pet result = client.toBlocking().retrieve(HttpRequest.GET("/pets/Dino"), Pet.class);

        assertNotNull(result);
        assertEquals("Dino", result.getName());

        result.setName("Heino");
        String url = "/pets/" + result.getId();
        HttpStatus status = client.toBlocking().retrieve(HttpRequest.PUT(url, result), HttpStatus.class);
        assertEquals(204, status.getCode());
    }
}

Then i got this Error:

javax.persistence.PersistenceException: org.hibernate.PersistentObjectException: detached entity passed to persist: example.domain.Pet
	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154)
	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)
	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188)
	at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:810)
	at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:788)

I discover the same error in my own project.
A direct Test with the Repository works.

Regards
Jan