When to use EntityManager find vs EntityManager getReference with JPA

Question

I have come across a situation  which I think is weird but is possibly quite normal  where I use the EntityManager getReference LObj getClass    LObj getId    to get a database entity and then pass the returned object to be persisted in another table   So basically the flow was like this    class TFacade     createT FObj  AObj        T TObj   new T        TObj setF FObj       TObj setA AObj               EntityManager persist TObj               L LObj   A getL        FObj setL LObj       FFacade editF FObj           TransactionAttributeType REQUIRES NEW class FFacade     editF FObj       L LObj   FObj getL        LObj   EntityManager getReference LObj getClass    LObj getId                 EntityManager merge FObj               FLHFacade create FObj  LObj           TransactionAttributeType REQUIRED class FLHFacade     createFLH FObj  LObj       FLH FLHObj   new FLH        FLHObj setF FObj       FLHObj setL LObj                EntityManager persist FLHObj                    I was getting the following exception  java lang IllegalArgumentException  Unknown entity  com my persistence L  EnhancerByCGLIB  3e7987d0   After looking into it for a while  I finally figured out that it was because I was using the EntityManager getReference   method that I was getting the above exception as the method was returning a proxy   This makes me wonder  when is it advisable to use the EntityManager getReference   method instead of the EntityManager find   method    EntityManager getReference   throws an EntityNotFoundException if it cant find the entity being searched for which is very convenient in itself  EntityManager find   method merely returns null if it cant find the entity   With regards to transaction boundaries  sounds to me like you would need to use the find   method before passing the newly found entity to a new transaction  If you use the getReference   method then you would probably end up in a situation similar to mine with the above exception

User · Answer

This makes me wonder  when is it advisable to use the   EntityManager getReference   method instead of the   EntityManager find   method    EntityManager getReference   is really an error prone method and there is really very few cases where a client code needs to use it  Personally  I never needed to use it      EntityManager getReference   and EntityManager find     no difference in terms of overhead  I disagree with the accepted answer and particularly       If i call find method  JPA provider  behind the scenes  will call  SELECT NAME  AGE FROM PERSON WHERE PERSON ID      UPDATE PERSON SET AGE     WHERE PERSON ID           If i call getReference method  JPA provider  behind the scenes  will   call  UPDATE PERSON SET AGE     WHERE PERSON ID        It is not the behavior that I get with Hibernate 5 and the javadoc of getReference   doesn t say such a thing        Get an instance  whose state may be lazily fetched  If the requested   instance does not exist in the database  the EntityNotFoundException   is thrown when the instance state is first accessed   The persistence   provider runtime is permitted to throw the EntityNotFoundException   when getReference is called   The application should not expect that   the instance state will be available upon detachment  unless it was   accessed by the application while the entity manager was open    EntityManager getReference   spares a query to retrieve the entity in two cases     1  if the entity is stored in the Persistence context  that is  the first level cache  And this behavior is not specific to EntityManager getReference     EntityManager find   will also spare a query to retrieve the entity if the entity is stored in the Persistence context       You can check the first point with any example  You can also rely on the actual Hibernate implementation  Indeed  EntityManager getReference   relies on the createProxyIfNecessary   method of the org hibernate event internal DefaultLoadEventListener class to load the  entity  Here is its implementation    private Object createProxyIfNecessary          final LoadEvent event          final EntityPersister persister          final EntityKey keyToLoad          final LoadEventListener LoadType options          final PersistenceContext persistenceContext        Object existing   persistenceContext getEntity  keyToLoad        if   existing    null                return existing object or initialized proxy  unless deleted          if   traceEnabled                 LOG trace   Entity found in session cache                       if   options isCheckDeleted                   EntityEntry entry   persistenceContext getEntry  existing                Status status   entry getStatus                if   status    Status DELETED    status    Status GONE                     return null                                  return existing            if   traceEnabled             LOG trace   Creating new proxy for entity                  return new uninitialized proxy     Object proxy   persister createProxy  event getEntityId    event getSession          persistenceContext getBatchFetchQueue   addBatchLoadableEntityKey  keyToLoad        persistenceContext addProxy  keyToLoad  proxy        return proxy      The interesting part is    Object existing   persistenceContext getEntity  keyToLoad      2  If we don t effectively manipulate the entity  echoing to the lazily fetched of the javadoc  Indeed  to ensure the effective loading of the entity  invoking a method on it is required  So the gain would be related to a scenario where we want to load a entity without having the need to use it   In the frame of applications  this need is really uncommon and in addition the getReference   behavior is also very misleading if you read the next part       Why favor EntityManager find   over EntityManager getReference     In terms of overhead  getReference   is not better than find   as discussed in the previous point  So why use the one or the other       Invoking getReference   may return a lazily fetched entity  Here  the lazy fetching doesn t refer to relationships of the entity but the entity itself  It means that if we invoke getReference   and then the Persistence context is closed  the entity may be never loaded and so the result is really unpredictable  For example if the proxy object is serialized  you could get a null reference as serialized result or if a method is invoked on the proxy object  an exception such as LazyInitializationException is thrown      It means that the throw of EntityNotFoundException that is the main reason to use getReference   to handle an instance that does not exist in the database as an error situation may be never performed while the entity is not existing      EntityManager find   doesn t have the ambition of throwing EntityNotFoundException if the entity is not found  Its behavior is both simple and clear  You will never have surprise as it returns always a loaded entity or null  if the entity is not found  but never an entity under the shape of a proxy that may not be effectively loaded  So EntityManager find   should be favored in the very most of cases

User · Answer

Because a reference is  managed   but not hydrated  it can also allow you to remove an entity by ID  without needing to load it into memory first   As you can t remove an unmanaged entity  it s just plain silly to load all fields using find      or createQuery       only to immediately delete it   MyLargeObject myObject   em getReference MyLargeObject class  objectId   em remove myObject

User · Answer

I disagree with the selected answer  and as davidxxx correctly pointed out  getReference does not provide such behaviour of dynamic updations without select  I asked a question concerning the validity of this answer  see here - cannot update without issuing select on using setter after getReference   of hibernate JPA   I quite honestly haven t seen anybody who s actually used that functionality  ANYWHERE  And i don t understand why it s so upvoted   Now first of all  no matter what you call on a hibernate proxy object  a setter or a getter  an SQL is fired and the object is loaded   But then i thought  so what if JPA getReference   proxy doesn t provide that functionality  I can just write my own proxy   Now  we can all argue that selects on primary keys are as fast as a query can get and it s not really something to go to great lengths to avoid  But for those of us who can t handle it due to one reason or another  below is an implementation of such a proxy  But before i you see the implementation  see it s usage and how simple it is to use   USAGE  Order example   ProxyHandler getReference Order class  3   example setType  ABCD    example setCost 10   PersistenceService save example     And this would fire the following query -  UPDATE Order SET type    ABCD  and cost   10 WHERE id   3    and even if you want to insert  you can still do PersistenceService save new Order  a   2    and it would fire an insert as it should   IMPLEMENTATION  Add this to your pom xml -   lt dependency gt   lt groupId gt cglib lt  groupId gt   lt artifactId gt cglib lt  artifactId gt   lt version gt 3 2 10 lt  version gt   lt  dependency gt    Make this class to create dynamic proxy -   SuppressWarnings  unchecked   public class ProxyHandler    public static  lt T gt  T getReference Class lt T gt  classType  Object id        if   classType isAnnotationPresent Entity class             throw new ProxyInstantiationException  This is not an entity                try           Enhancer enhancer   new Enhancer            enhancer setSuperclass classType           enhancer setCallback new ProxyMethodInterceptor classType  id            enhancer setInterfaces  new Class lt   gt    EnhancedProxy class             return  T  enhancer create          catch  Exception e            throw new ProxyInstantiationException  Error creating proxy  cause      e getCause               Make an interface with all the methods -   public interface EnhancedProxy       public String getJPQLUpdate        public HashMap lt String  Object gt  getModifiedFields        Now  make an interceptor which will allow you to implement these methods on your proxy -  import com anil app exception ProxyInstantiationException  import javafx util Pair  import net sf cglib proxy MethodInterceptor  import net sf cglib proxy MethodProxy   import javax persistence Id  import java lang reflect Field  import java lang reflect Method  import java util           author Anil Kumar    public class ProxyMethodInterceptor implements MethodInterceptor  EnhancedProxy    private Object target  private Object proxy  private Class classType  private Pair lt String  Object gt  primaryKey  private static HashSet lt String gt  enhancedMethods   ProxyMethodInterceptor Class classType  Object id  throws IllegalAccessException  InstantiationException       this classType   classType      this target   classType newInstance        this primaryKey   new Pair lt  gt  getPrimaryKeyField   getName    id      static       enhancedMethods   new HashSet lt  gt         for  Method method   EnhancedProxy class getDeclaredMethods              enhancedMethods add method getName               Override public Object intercept Object obj  Method method  Object   args  MethodProxy proxy  throws Throwable         intercept enhanced methods     if  enhancedMethods contains method getName               this proxy   obj          return method invoke this  args               else invoke super class method     else         return proxy invokeSuper obj  args       Override public HashMap lt String  Object gt  getModifiedFields         HashMap lt String  Object gt  modifiedFields   new HashMap lt  gt         try           for  Field field   classType getDeclaredFields                   field setAccessible true                Object initialValue   field get target               Object finalValue   field get proxy                  put if modified             if   Objects equals initialValue  finalValue                     modifiedFields put field getName    finalValue                                 catch  Exception e            return null            return modifiedFields      Override public String getJPQLUpdate         HashMap lt String  Object gt  modifiedFields   getModifiedFields        if  modifiedFields    null    modifiedFields isEmpty              return null            StringBuilder fieldsToSet   new StringBuilder        for  String field   modifiedFields keySet              fieldsToSet append field  append         append field  append   and               fieldsToSet setLength fieldsToSet length   - 4       return  UPDATE                 classType getSimpleName                   SET                 fieldsToSet                WHERE                 primaryKey getKey             primaryKey getValue       private Field getPrimaryKeyField   throws ProxyInstantiationException       for  Field field   classType getDeclaredFields              field setAccessible true           if  field isAnnotationPresent Id class               return field            throw new ProxyInstantiationException  Entity class doesn t have a primary key           And the exception class -   public class ProxyInstantiationException extends RuntimeException   public ProxyInstantiationException String message        super message       A service to save using this proxy -    Service public class PersistenceService     PersistenceContext private EntityManager em    Transactional private void save Object entity           update entity for proxies     if  entity instanceof EnhancedProxy            EnhancedProxy proxy    EnhancedProxy  entity          Query updateQuery   em createQuery proxy getJPQLUpdate             for  Entry lt String  Object gt  entry   proxy getModifiedFields   entrySet                  updateQuery setParameter entry getKey    entry getValue                       updateQuery executeUpdate           insert otherwise       else           em persist entity

User · Answer

Sssuming you have a parent Post entity and a child PostComment as illustrated in the following diagram   If you call find when you try to set the  ManyToOne post association  PostComment comment   new PostComment    comment setReview  quot Just awesome  quot      Post post   entityManager find Post class  1L   comment setPost post     entityManager persist comment    Hibernate will execute the following statements  SELECT p id AS id1 0 0          p title AS title2 0 0  FROM   post p WHERE p id   1   INSERT INTO post comment  post id  review  id  VALUES  1   Just awesome    1   The SELECT query is useless this time because we don   t need the Post entity to be fetched  We only want to set the underlying post id Foreign Key column  Now  if you use getReference instead  PostComment comment   new PostComment    comment setReview  quot Just awesome  quot      Post post   entityManager getReference Post class  1L   comment setPost post     entityManager persist comment    This time  Hibernate will issue just the INSERT statement  INSERT INTO post comment  post id  review  id  VALUES  1   Just awesome    1   Unlike find  the getReference only returns an entity Proxy which only has the identifier set  If you access the Proxy  the associated SQL statement will be triggered as long as the EntityManager is still open  However  in this case  we don   t need to access the entity Proxy  We only want to propagate the Foreign Key to the underlying table record so loading a Proxy is sufficient for this use case  When loading a Proxy  you need to be aware that a LazyInitializationException can be thrown if you try to access the Proxy reference after the EntityManager is closed

User · Answer

I usually use getReference method when i do not need to access database state  I mean getter method   Just to change state  I mean setter method   As you should know  getReference returns a proxy object which uses a powerful feature called automatic dirty checking  Suppose the following  public class Person        private String name      private Integer age       public class PersonServiceImpl implements PersonService        public void changeAge Integer personId  Integer newAge            Person person   em getReference Person class  personId               person is a proxy         person setAge newAge              If i call find method  JPA provider  behind the scenes  will call  SELECT NAME  AGE FROM PERSON WHERE PERSON ID      UPDATE PERSON SET AGE     WHERE PERSON ID       If i call getReference method  JPA provider  behind the scenes  will call  UPDATE PERSON SET AGE     WHERE PERSON ID       And you know why      When you call getReference  you will get a proxy object  Something like this one  JPA provider takes care of implementing this proxy   public class PersonProxy           JPA provider sets up this field when you call getReference     private Integer personId       private String query    UPDATE PERSON SET         private boolean stateChanged   false       public void setAge Integer newAge            stateChanged   true           query    query    AGE       newAge             So before transaction commit  JPA provider will see stateChanged flag in order to update OR NOT person entity  If no rows is updated after update statement  JPA provider will throw EntityNotFoundException according to JPA specification   regards

[java] When to use EntityManager.find() vs EntityManager.getReference() with JPA

EntityManager.getReference() and EntityManager.find() : no difference in terms of overhead

Why favor EntityManager.find() over EntityManager.getReference()

Examples related to java

Examples related to jakarta-ee

Examples related to jpa

Examples related to persistence