What is the difference between get and load methods when hibernate loads data?

The difference between get and load methods when hibernate loads data. Let's take a look at the method prototype first:

1. Get Method

/**
* Return the persistent instance of the given entity class with the given identifier,
* Or null if there is no such persistent instance. (If the instance, or a proxy for
* Instance, is already associated with the session, return that instance or proxy .)
*
* @ Param clazz a persistent class
* @ Param id an identifier
* @ Return a persistent instance or null
* @ Throws hibernateexception
*/
Public object get (class clazz, serializable ID) throws hibernateexception;

2. Load Method

/**
* Return the persistent instance of the given entity class with the given identifier,
* Assuming that the instance exists.
* <Br>
* You shoshould not use this method to determine if an instance exists (use <tt> get () </tt>
* Instead). Use this only to retrieve an instance that you assume exists, where non-existence
* Wocould be an actual error.
*
* @ Param theclass a persistent class
* @ Param ID a valid identifier of an existing persistent instance of the class
* @ Return the persistent instance or proxy
* @ Throws hibernateexception
*/

After comparison, we can find that: Session.Load/GetYou can read records from the database based on the specified object class and ID, and return the corresponding object. The difference is:

1. If a qualified record is not found,GetMethod returns NULL, whileLoadMethod will throw an objectnotfoundexception.
2. LoadThe method returns the proxy instance of the object.GetThe method always returns the object class.
3. LoadThe method can make full use of the existing data in the internal cache and the second-level cache.GetThe method only searches for data in the internal cache. If no corresponding data is found, it will go beyond the second-level cache and directly call SQL to complete data reading.

When a session loads an object, it goes through the following process:

1. First,HibernateTwo levels of cache are maintained. The first level of cache is maintained by the session instance, which maintains the data of all associated entities of the session, also known as the internal cache. The second-level cache exists at the sessionfactory level and is shared by all session instances constructed by the current sessionfactory. In order to avoid unnecessary database access for performance consideration, session queries in the cache before calling the database query function. First, in the first-level cache, the object type and ID are used for search. If the first-level cache query hits and the data status is valid, the system returns the result directly.
2. Then, the session will be searched in the current "nonexists" record. If the "nonexists" record has the same query condition, null is returned. "Nonexists" records the query conditions of the current session instance in all previous query operations, and the query conditions of valid data cannot be queried (equivalent to a query blacklist list ). In this way, if an invalid query condition reoccurs in the session, you can quickly make a judgment to obtain the best performance.
3. ForLoadIf no valid data is found in the internal cache, the second-level cache is queried. If the second-level cache hits, the second-level cache is returned.
4. If no valid data is found in the cache, the database query operation (select SQL) is initiated. If no corresponding record is found after the query, the query information is recorded in "nonexists, and return null.
5. Create the corresponding data object based on the resultset obtained by the ing configuration and select SQL.
6. Include the data objects in the current Session Object Management container (level-1 cache ).
7. Execute the Interceptor. onload method (if there is a corresponding interceptor ).
8. Include data objects in the second-level cache.
9. If the data object implements the lifecycle interface, the onload method of the data object is called.
10. Returns the data object.