What is the proper way to re-attach detached objects in Hibernate

Question

I have a situation in which I need to re-attach detached objects to a hibernate session  although an object of the same identity MAY already exist in the session  which will cause errors   Right now  I can do one of two things    getHibernateTemplate   update  obj   This works if and only if an object doesn t already exist in the hibernate session  Exceptions are thrown stating an object with the given identifier already exists in the session when I need it later  getHibernateTemplate   merge  obj   This works if and only if an object exists in the hibernate session  Exceptions are thrown when I need the object to be in a session later if I use this    Given these two scenarios  how can I generically attach sessions to objects  I don t want to use exceptions to control the flow of this problem s solution  as there must be a more elegant solution

User · Answer

If you are sure that your entity has not been modified (or if you agree any modification will be lost), then you may reattach it to the session with lock.

session.lock(entity, LockMode.NONE);

It will lock nothing, but it will get the entity from the session cache or (if not found there) read it from the DB.

It's very useful to prevent LazyInitException when you are navigating relations from an "old" (from the HttpSession for example) entities. You first "re-attach" the entity.

Using get may also work, except when you get inheritance mapped (which will already throw an exception on the getId()).

entity = session.get(entity.getClass(), entity.getId());

User · Answer

to reattach this object  you must use merge     this methode accept in parameter your entity detached and return an entity will be attached and reloaded from Database   Example       Lot objAttach   em merge oldObjDetached       objAttach setEtat           em persist objAttach

User · Answer

I went back to the JavaDoc for org hibernate Session and found the following      Transient instances may be made persistent by calling save    persist   or    saveOrUpdate    Persistent instances may be made transient by calling delete    Any instance returned by a get   or load   method is persistent  Detached instances may be made persistent by calling update    saveOrUpdate    lock   or replicate    The state of a transient or detached instance may also be made persistent as a new persistent instance by calling merge      Thus update    saveOrUpdate    lock    replicate   and merge   are the candidate options   update    Will throw an exception if there is a persistent instance with the same identifier   saveOrUpdate    Either save or update  lock    Deprecated  replicate    Persist the state of the given detached instance  reusing the current identifier value   merge    Returns a persistent object with the same identifier  The given instance does not become associated with the session   Hence  lock   should not be used straightway and based on the functional requirement one or more of them can be chosen

User · Answer

try getHibernateTemplate   replicate entity ReplicationMode LATEST VERSION

User · Answer

Undiplomatic answer  You re probably looking for an extended persistence context   This is one of the main reasons behind the Seam Framework    If you re struggling to use Hibernate in Spring in particular  check out this piece of Seam s docs   Diplomatic answer  This is described in the Hibernate docs   If you need more clarification  have a look at Section 9 3 2 of Java Persistence with Hibernate called  Working with Detached Objects    I d strongly recommend you get this book if you re doing anything more than CRUD with Hibernate

User · Answer

Perhaps it behaves slightly different on Eclipselink  To re-attach detached objects without getting stale data  I usually do   Object obj   em find obj getClass    id     and as an optional a second step  to get caches invalidated     em refresh obj

User · Answer

calling first merge    to update persistent instance   then lock LockMode NONE   to attach the current instance  not the one returned by merge    seems to work for some use cases

User · Answer

So it seems that there is no way to reattach a stale detached entity in JPA   merge   will push the stale state to the DB   and overwrite any intervening updates   refresh   cannot be called on a detached entity   lock   cannot be called on a detached entity  and even if it could  and it did reattach the entity  calling  lock  with argument  LockMode NONE   implying that you are locking  but not locking   is the most counterintuitive piece of API design I ve ever seen   So you are stuck  There s an detach   method  but no attach   or reattach    An obvious step in the object lifecycle is not available to you   Judging by the number of similar questions about JPA  it seems that even if JPA does claim to have a coherent model   it most certainly does not match the mental model of most programmers  who have been cursed to waste many hours trying understand  how to get JPA to do the simplest things  and end up with cache  management code all over their applications   It seems the only way to do it is discard your stale detached entity  and do a find query with the same id  that will hit the L2 or the DB   Mik

User · Answer

In the original post  there are two methods  update obj  and merge obj  that are mentioned to work  but in opposite circumstances   If this is really true  then why not test to see if the object is already in the session first  and then call update obj  if it is  otherwise call merge obj      The test for existence in the session is session contains obj    Therefore  I would think the following pseudo-code would work   if  session contains obj         session update obj     else        session merge obj

User · Answer

Session contains Object obj  checks the reference and will not detect a different instance that represents the same row and is already attached to it   Here my generic solution for Entities with an identifier property   public static void update final Session session  final Object entity           if the given instance is in session  nothing to do     if  session contains entity           return          check if there is already a different attached instance representing the same row     final ClassMetadata classMetadata   session getSessionFactory   getClassMetadata entity getClass         final Serializable identifier   classMetadata getIdentifier entity   SessionImplementor  session        final Object sessionEntity   session load entity getClass    identifier          override changes  last call to update wins     if  sessionEntity    null          session evict sessionEntity       session update entity       This is one of the few aspects of  Net EntityFramework I like  the different attach options regarding changed entities and their properties

User · Answer

Property hibernate allow refresh detached entity did the trick for me  But it is a general rule  so it is not very suitable if you want to do it only in some cases  I hope it helps   Tested on Hibernate 5 4 9  SessionFactoryOptionsBuilder

User · Answer

I came up with a solution to  refresh  an object from the persistence store that will account for other objects which may already be attached to the session   public void refreshDetached T entity  Long id           Check for any OTHER instances already attached to the session since        refresh will not work if there are any      T attached    T  session load getPersistentClass    id       if  attached    entity                session evict attached           session lock entity  LockMode NONE             session refresh entity

User · Answer

Hibernate support reattach detached entity by serval ways  see Hibernate user guide

User · Answer

Sorry  cannot seem to add comments  yet     Using Hibernate 3 5 0-Final  Whereas the Session lock method this deprecated  the javadoc does suggest using Session buildLockRequest LockOptions  lock entity and if you make sure your associations have cascade lock  the lazy-loading isn t an issue either   So  my attach method looks a bit like  MyEntity attach MyEntity entity        if getSession   contains entity   return entity      getSession   buildLockRequest LockOptions NONE  lock entity       return entity    Initial tests suggest it works a treat

User · Answer

I did it that way in C  with NHibernate  but it should work the same way in Java   public virtual void Attach         if   HibernateSessionManager Instance GetSession   Contains this                 ISession session   HibernateSessionManager Instance GetSession            using  ITransaction t   session BeginTransaction                          session Lock this  NHibernate LockMode None               t Commit                        First Lock was called on every object because Contains was always false  The problem is that NHibernate compares objects by database id and type  Contains uses the equals method  which compares by reference if it s not overwritten  With that equals method it works without any Exceptions   public override bool Equals object obj        if  this    obj             return true             if  GetType      obj GetType              return false            if  Id      BaseObject obj  Id                return false            return true

User · Answer

All of these answers miss an important distinction  update   is used to  re attach your object graph to a Session  The objects you pass it are the ones that are made managed     merge   is actually not a  re attachment API  Notice merge   has a return value  That s because it returns you the managed graph  which may not be the graph you passed it  merge   is a JPA API and its behavior is governed by the JPA spec  If the object you pass in to merge   is already managed  already associated with the Session  then that s the graph Hibernate works with  the object passed in is the same object returned from merge    If  however  the object you pass into merge   is detached  Hibernate creates a new object graph that is managed and it copies the state from your detached graph onto the new managed graph  Again  this is all dictated and governed by the JPA spec   In terms of a generic strategy for  make sure this entity is managed  or make it managed   it kind of depends on if you want to account for not-yet-inserted data as well  Assuming you do  use something like  if   session contains  myEntity              nothing to do    myEntity is already associated with the session   else       session saveOrUpdate  myEntity        Notice I used saveOrUpdate   rather than update    If you do not want not-yet-inserted data handled here  use update   instead

User · Answer

try getHibernateTemplate   saveOrUpdate

User · Answer

Entity states JPA defines the following entity states  New  Transient  A newly created object that hasn   t ever been associated with a Hibernate Session  a k a Persistence Context  and is not mapped to any database table row is considered to be in the New  Transient  state  To become persisted we need to either explicitly call the EntityManager persist method or make use of the transitive persistence mechanism  Persistent  Managed  A persistent entity has been associated with a database table row and it   s being managed by the currently running Persistence Context  Any change made to such an entity is going to be detected and propagated to the database  during the Session flush-time   With Hibernate  we no longer have to execute INSERT UPDATE DELETE statements  Hibernate employs a transactional write-behind working style and changes are synchronized at the very last responsible moment  during the current Session flush-time  Detached Once the currently running Persistence Context is closed all the previously managed entities become detached  Successive changes will no longer be tracked and no automatic database synchronization is going to happen  Entity state transitions You can change the entity state using various methods defined by the EntityManager interface  To understand the JPA entity state transitions better  consider the following diagram   When using JPA  to reassociate a detached entity to an active EntityManager  you can use the merge operation  When using the native Hibernate API  apart from merge  you can reattach a detached entity to an active Hibernate Sessionusing the update methods  as demonstrated by the following diagram   Merging a detached entity The merge is going to copy the detached entity state  source  to a managed entity instance  destination   Consider we have persisted the following Book entity  and now the entity is detached as the EntityManager that was used to persist the entity got closed  Book  book   doInJPA entityManager - gt        Book book   new Book        setIsbn  quot 978-9730228236 quot        setTitle  quot High-Performance Java Persistence quot        setAuthor  quot Vlad Mihalcea quot          entityManager persist book         return book       While the entity is in the detached state  we modify it as follows   book setTitle       quot High-Performance Java Persistence  2nd edition quot      Now  we want to propagate the changes to the database  so we can call the merge method  doInJPA entityManager - gt        Book book   entityManager merge  book         LOGGER info  quot Merging the Book entity quot          assertFalse book     book        And Hibernate is going to execute the following SQL statements  SELECT     b id      b author AS author2 0       b isbn AS isbn3 0       b title AS title4 0  FROM     book b WHERE     b id   1   -- Merging the Book entity   UPDATE     book SET     author    Vlad Mihalcea       isbn    978-9730228236       title    High-Performance Java Persistence  2nd edition  WHERE     id   1  If the merging entity has no equivalent in the current EntityManager  a fresh entity snapshot will be fetched from the database  Once there is a managed entity  JPA copies the state of the detached entity onto the one that is currently managed  and during the Persistence Context flush  an UPDATE will be generated if the dirty checking mechanism finds that the managed entity has changed   So  when using merge  the detached object instance will continue to remain detached even after the merge operation   Reattaching a detached entity Hibernate  but not JPA supports reattaching through the update method  A Hibernate Session can only associate one entity object for a given database row  This is because the Persistence Context acts as an in-memory cache  first level cache  and only one value  entity  is associated with a given key  entity type and database identifier   An entity can be reattached only if there is no other JVM object  matching the same database row  already associated with the current Hibernate Session  Considering we have persisted the Book entity and that we modified it when the Book entity was in the detached state  Book  book   doInJPA entityManager - gt        Book book   new Book        setIsbn  quot 978-9730228236 quot        setTitle  quot High-Performance Java Persistence quot        setAuthor  quot Vlad Mihalcea quot          entityManager persist book         return book              book setTitle       quot High-Performance Java Persistence  2nd edition quot      We can reattach the detached entity like this  doInJPA entityManager - gt        Session session   entityManager unwrap Session class         session update  book         LOGGER info  quot Updating the Book entity quot         And Hibernate will execute the following SQL statement  -- Updating the Book entity   UPDATE     book SET     author    Vlad Mihalcea       isbn    978-9730228236       title    High-Performance Java Persistence  2nd edition  WHERE     id   1   The update method requires you to unwrap the EntityManager to a Hibernate Session   Unlike merge  the provided detached entity is going to be reassociated with the current Persistence Context and an UPDATE is scheduled during flush whether the entity has modified or not  To prevent this  you can use the  SelectBeforeUpdate Hibernate annotation which will trigger a SELECT statement that fetched loaded state which is then used by the dirty checking mechanism   Entity name    quot Book quot    Table name    quot book quot    SelectBeforeUpdate public class Book           Code omitted for brevity    Beware of the NonUniqueObjectException One problem that can occur with update is if the Persistence Context already contains an entity reference with the same id and of the same type as in the following example  Book  book   doInJPA entityManager - gt        Book book   new Book        setIsbn  quot 978-9730228236 quot        setTitle  quot High-Performance Java Persistence quot        setAuthor  quot Vlad Mihalcea quot          Session session   entityManager unwrap Session class       session saveOrUpdate book         return book         book setTitle       quot High-Performance Java Persistence  2nd edition quot       try       doInJPA entityManager - gt            Book book   entityManager find              Book class               book getId                        Session session   entityManager unwrap Session class           session saveOrUpdate  book             catch  NonUniqueObjectException e        LOGGER error           quot The Persistence Context cannot hold  quot             quot two representations of the same entity quot           e           Now  when executing the test case above  Hibernate is going to throw a NonUniqueObjectException because the second EntityManager already contains a Book entity with the same identifier as the one we pass to update  and the Persistence Context cannot hold two representations of the same entity  org hibernate NonUniqueObjectException      A different object with the same identifier value was already associated with the session    com vladmihalcea book hpjp hibernate pc Book 1      at org hibernate engine internal StatefulPersistenceContext checkUniqueness StatefulPersistenceContext java 651      at org hibernate event internal DefaultSaveOrUpdateEventListener performUpdate DefaultSaveOrUpdateEventListener java 284      at org hibernate event internal DefaultSaveOrUpdateEventListener entityIsDetached DefaultSaveOrUpdateEventListener java 227      at org hibernate event internal DefaultSaveOrUpdateEventListener performSaveOrUpdate DefaultSaveOrUpdateEventListener java 92      at org hibernate event internal DefaultSaveOrUpdateEventListener onSaveOrUpdate DefaultSaveOrUpdateEventListener java 73      at org hibernate internal SessionImpl fireSaveOrUpdate SessionImpl java 682      at org hibernate internal SessionImpl saveOrUpdate SessionImpl java 674   Conclusion The merge method is to be preferred if you are using optimistic locking as it allows you to prevent lost updates  The update is good for batch updates as it can prevent the additional SELECT statement generated by the merge operation  therefore reducing the batch update execution time

[java] What is the proper way to re-attach detached objects in Hibernate?

Examples related to java

Examples related to hibernate

Examples related to spring

Examples related to session

Examples related to detach