How does jpa merge work

If you ever use an assigned identifier generator, you have to remember to add a Java Wrapper Version property, otherwise, a redundant SELECT statement is going to be generated. However, while reviewing lots of projects, I came to realize that the following anti-pattern is rather widespread:. The save method serves no purpose. Even if we remove it, Hibernate will still issue the UPDATE statement since the entity is managed and any state change is propagated as long as the currently running EntityManager is open.

This is an anti-pattern because the save call fires a MergeEvent which is handled by the DefaultMergeEventListener which does the following operations:.

In the copyValues method call, the hydrated state is copied again, so a new array is redundantly created, therefore wasting CPU cycles. If the entity has child associations and the merge operation is also cascaded from parent to child entities , the overhead is even greater because each child entity will propagate a MergeEvent and the cycle continues. While a save method might be convenient in some situations, in practice, you should never call merge for entities that are either new or already managed.

For new entities, you should always use persist , while for detached entities you need to call merge. Category: Hibernate Tags: hibernate , jpa , tips , Training , Tutorial. Your email address will not be published.

Notify me of follow-up comments by email. This site uses Akismet to reduce spam. Learn how your comment data is processed. Vlad Mihalcea. Log into your account.

Privacy Policy. Password recovery. Forgot your password? Get help. Java News. Home Hibernate Merge - Re attaching detached Entities. Merge — Re attaching detached Entities. By Satish Varma. When the transaction is committed, or if the persistence context is flushed , then the object will be updated in the database.

Normally merge is not required, although it is frequently misused. To update an object you simply need to read it, then change its state through its set methods, then commit the transaction. The EntityManager will figure out everything that has been changed and update the database. A detached object is one that was read through a different EntityManager or in a different transaction in a JEE managed EntityManager , or one that was cloned, or serialized.

A common case is a stateless SessionBean where the object is read in one transaction, then updated in another transaction. Since the update is processed in a different transaction, with a different EntityManager , it must first be merged. The merge operation can only be called within a transaction, an exception will be thrown outside of a transaction.

The merge operation is not in-place, in that the object being merged will never become part of the persistence context. Any further changes must be made to the managed object returned by the merge , not the detached object. If the object is new, a new copy of the object will be made and registered with the persistence context, the detached object will not be persisted itself. Embeddable objects are automatically merged as part of their owning Entity.

Calling merge on an object will also cascade the merge operation across any relationship that is marked as cascade merge. Even if the relationship is not cascade merge, the reference will still be merged. If the relationship is cascade merge the relationship and each related object will be merged.

Intuitively you may consider marking every relationship as cascade merge to avoid having to worry about calling merge on every objects, but this is normally a bad idea.

One issue with marking all relationships cascade merge is performance. If you have an object with a lot of relationships, then each merge call can require to traverse a large graph of objects. Another issues arises if your detached object is corrupt in some way. For example say you have an Employee who has a manager , but that manager has a different copy of the detached Employee object as its managedEmployee.

This may cause the same object to be merged twice, or at least may not be consistent which object will be merged, so you may not get the changes you expect merged. The same is true if you didn't change an object at all, but some other user did, if merge cascades to this unchanged object, it will revert the other user's changes, or throw an OptimisticLockException depending on your locking policy.

This is normally not desirable. I would recommend only marking relationships that are composite or privately owned as cascade merge. Another issue with merge is transient variables.

Since merge is normally used with object serialization, if a relationship was marked as transient Java transient, not JPA transient , then the detached object will contain null , and null will be merged into the object, even though it is not desired. This will occur even if the relationship was not cascade merge, as merge always merges the references to related objects.

Normally transient is required when using serialization to avoid serializing the entire database when only a single, or small set of objects are required. One solution is to avoid marking anything transient , and instead use LAZY relationships in JPA to limit what is serialized lazy relationships that have not been accessed, will normally not be serialized.

Another solution is to manually merge in your own code. Some JPA providers provide extended merge operations, such as allowing a shallow merge or deep merge, or merging without merging references. When the transaction is committed, or if the persistence context is flushed , then the object will be deleted from the database.

The remove operation can only be called within a transaction, an exception will be thrown outside of a transaction. The remove operation must be called on a managed object, not on a detached object. Generally you must first find the object before removing it, although it is possible to call EntityManager. Depending on how you JPA provider optimizes getReference and remove , it may not require reading the object from the database.

Embeddable objects are automatically removed as part of their owning Entity. Calling remove on an object will also cascade the remove operation across any relationship that is marked as cascade remove. Note that cascade remove only effects the remove call. If you have a relationship that is cascade remove, and remove an object from the collection, or dereference an object, it will not be removed. You must explicitly call remove on the object to have it deleted.

Normally an object that has been removed, stays removed, but in some cases you may need to bring the object back to life. This normally occurs with natural ids, not generated ones, where a new object would always get an new id. Generally the desire to reincarnate an object occurs from a bad object model design, normally the desire to change the class type of an object which cannot be done in Java, so a new object must be created.

Normally the best solution is to change your object model to have your object hold a type object which defines its type, instead of using inheritance. But sometimes reincarnation is desirable. When done in two separate transactions, this is normally fine, first you remove the object, then you persist it back.