The real difference between the get and load methods of session in Hibernate

Recently in the Learning Shh framework of Hibernate, the Get and load methods of the session, a little confused, do not know where the difference, or the difference between them is not deep. So Baidu a bit, the result of the problem came. The results of Baidu and the actual test results are very large. The main idea is that the Get method is inconsistent with the actual running results.

Let's start with the idea that:

• Get does not support lazy,load support lazy;
• When the data does not exist, get returns Null,load throws a Objectnotfoundexception exception.
• The Load method can return an instance of a proxy class for an entity, and the Get method directly reads the database, so it returns the entity class directly (the claim for Get is wrong)

As for the first article, I believe that we do not have much doubt. Let me give you an example: lazy means to execute an SQL statement when it is used.

1. User user = (user) session.load (user).      Class,"4028981b41174a690141174a6c6d0003");

This code does not execute the database query, but only when the user is used to execute the database query. Therefore, SQL statements are not generated immediately.

1. User user = (user) session.get (user).       Class, "4028981b41174a690141174a6c6d0003");

The code above immediately executes the database query (if there are no instances in the cache).

And the next question, to be clear, is to first understand a problem--session the process of loading an entity object:

First, a level two cache is maintained in Hibernate. The first level of caching is maintained by the session instance, which is a transaction-scoped cache. It maintains data for all associated entities of the session, also known as internal caches. The second-level cache exists at the sessionfactory level, which is a process-wide or cluster-wide cache that is shared by all current session instances constructed by this sessionfactory.

For performance reasons, to avoid unnecessary database access, the session will be queried in the cache before invoking the database query function. First-level cache (internal cache), the entity type and ID to find, if the first-level cache lookup hit, and the data state is legitimate, it is returned directly. The session is then searched in the current "nonexists" record, and Null is returned if the same query condition exists in the "nonexists" record. "Nonexists" records the current session instance in all previous query operations, failed to query the valid data query criteria (equivalent to a query blacklist list). As a result, if an invalid query condition recurs in the session, you can quickly make a judgment to get the best performance.

For the Load method, the internal cache is looked up first, if the hit, the instance is returned, and if no valid data is found in the internal cache, the second-level cache is queried and returned if the second-level cache hits. If no valid data is still found in the level two cache, initiate a database query operation (Select SQL). Returns the entity class if the query is Proxy Object, if the query does not find the corresponding record, the information of this query is recorded in "Nonexists", and throws a Objectnotfoundexception exception. For the Get method, Many of the books, the Web blogs are wrong。 The Get method is also the first to find the internal cache, if hit, then return, or initiate a database query operation, if the query to, then return the entity class object, if the query did not find the corresponding record, the information of this query is recorded in "Nonexists", and returns NULL. So what the web says is "when someone modifies the data, the load may not read the latest data, and get will definitely read the latest modified data." not establishedOf       This means that the Get method is not necessarily the entity class object, nor does the Load method return the Entity proxy class object. The above view is I pass the test to arrive, has the code to have the picture to have the truth:

2. Package com.bjpowernode.hibernate;
6. Import Java.util.Date;
10. Import Junit.framework.TestCase;
14. Import org.hibernate.ObjectNotFoundException;
16. Import org.hibernate.Session;
18. Import org.hibernate.Transaction;
22. /**
24. * Session Test Class
26. *
28. * @author Longxuan
30. *
32. */
34. Public class Sessiontest extends TestCase {
38. public void Testequals () {
40. Session session = null;
42. try {
46. //Get session
48. Session = Hibernateutils.getsession ();
50. //Open transaction
52. Session.begintransaction ();
54. System.out.println ("\n\n\n\n");
56. try {
60. //Verify that the Get returns Null,load throw Objectnotfoundexception exception when data is not found
62. System.out.println (Session.get (User.   class, "123"));
64. System.out.println (Session.load (User.   class, "123"));
68. } catch (Objectnotfoundexception e) {
72. System.out.println ("Load method throws Objectnotfoundexception exception");
76. }
80. System.out.println ("\ n");
88. //Verify that Load returns an entity class object, not a proxy object
90. {
92. User User1 = (user) session.get (user).   Class,"4028981b41174a690141174a6c6d0003");
94. User User2 = (user) session.load (user).   Class,"4028981b41174a690141174a6c6d0003");
96. System.out.println ("user1:" + user1.getclass (). Getsimplename ());
98. System.out.println ("user2:" + user2.getclass (). Getsimplename ());
100. System.out.println ("User1 and User2 are the same object:" + user1.equals (user2));
102. }
106. System.out.println ("\ n");
108. Session.clear (); //Clear Session
114. //Verify get can also return a proxy class object without necessarily returning an entity class object
116. ///Verify that the Get method finds the cache first (if there is no output SQL statement, the get finds the cache)
118. {
120. User User3 = (user) session.load (user).   Class,"4028981b41174a690141174a6c6d0003");
122. User User4 = (user) session.get (user).   Class,"4028981b41174a690141174a6c6d0003");
124. System.out.println ("User3:" + user3.getclass (). Getsimplename ());
126. System.out.println ("user4:" + user4.getclass (). Getsimplename ());
128. System.out.println ("User3 and User4 are the same object:" + user3.equals (user4));
130. }
136. Session.gettransaction (). commit ();
140. } catch (Exception e) {
144. E.printstacktrace ();
146. Session.gettransaction (). rollback ();
150. } finally {
152. Hibernateutils.closesession (session);
154. }
158. }
160. }

Run the result diagram:
There is also an interesting phenomenon:

1. User User5 = (user) session.load (user).        class, "123");
2. System.out.println (User5.getid ());

Running results direct output 123 from the results, it can be seen that the first 2 lines of code do not perform database operations. Since load will store a map object in the Hibernate cache, the map key is the value of the ID, but when you GetID (), it will go to the first-level cache to take the map key value, just found, so no more to execute the database query. and will not report any mistakes. The results are as above.

The real difference between the get and load methods of session in Hibernate