Recently in the Learning Shh framework of the Hibernate, the session of Get and load methods, a little confused, do not know where the difference, or the difference between their feelings are not deep. So Baidu a bit, the result of the problem came. Baidu's results and the actual test results are very large. The main idea is that the Get method is inconsistent with the results of the actual operation.
Let's talk about the point:
Get does not support lazy,load support lazy;
When the data does not exist, the get return null,load throws the objectnotfoundexception exception.
The Load method can return the proxy class instance of the entity, and the Get method directly reads the database, so it is wrong to return the entity class directly (GET)
As for the first article, I believe we do not have too many questions. Let me give you an example: lazy means to execute the SQL statement when it is used.
User user = (user) session.load (user.class, "4028981b41174a690141174a6c6d0003");
This code does not execute the database query, only when the user is used to execute the database query. Therefore, SQL statements are not generated immediately.
User user = (user) Session.get (user.class, "4028981b41174a690141174a6c6d0003"); The above code then executes the database query immediately (if there are no instances in the cache).
And the next question to be clear, first to understand a problem--session the process of loading entity objects:
First, a level two cache is maintained in Hibernate. The first level cache is maintained by the session instance, which is a transaction-scoped cache. It maintains the data for all current associated entities of the session, also known as internal caching. The second-level cache exists at the sessionfactory level, which is part of a process-wide or cluster-wide cache, shared by all current session instances constructed by this sessionfactory.
For performance reasons, avoid unnecessary database access, the session in the database query function before calling, will first query in the cache. First-level cache (internal cache) is searched by entity type and ID, and returns directly if the first level cache lookup hits and the data state is valid. The session is then looked up in the current nonexists record and null if the same query condition exists in the nonexists record. "Nonexists" records a query condition (equivalent to a list of query blacklists) in which the current session instance failed to query for valid data in all previous query operations. As a result, if an invalid query condition in the session repeats itself, the decision can be made quickly to get the best performance.
For the Load method, first look for the internal cache, if hit, return the instance, and if no valid data is found in the internal cache, query the second level cache and return if the second level cache hits. If no valid data is still found in the level two cache, the database query operation (Select SQL) is initiated. If a query is made, returns the proxy object for the entity class, and if the corresponding record is not found in the query, the information for this query is recorded in "Nonexists" and the Objectnotfoundexception exception is thrown.
For Get methods, many books and web blogs are wrong. The Get method is also to find the internal cache first, if hit, then return, otherwise the database query operation, if the query to, then return the object of the entity class, if the query did not find the corresponding records, then the query information in "Nonexists" in the record, and return null. So it's not true that "when someone modifies the data, the load may not read the latest data, and get can definitely read the latest modified data".
This means that the Get method does not necessarily acquire an entity class object, nor does the Load method return an Entity proxy class object.
The above point is that I have passed the test, there is the code has a picture of the truth AH:
Package com.bjpowernode.hibernate;
Import Java.util.Date;
Import Junit.framework.TestCase;
Import org.hibernate.ObjectNotFoundException;
Import org.hibernate.Session;
Import org.hibernate.Transaction; /** * Session Test class * * @author Longxuan * */public class Sessiontest extends TestCase {public voi
D Testequals () {session session = NULL;
try {//Get session session = Hibernateutils.getsession ();
Open transaction session.begintransaction ();
System.out.println ("\n\n\n\n"); try {//Verify no data is found, get returns Null,load throw Objectnotfoundexception exception//url:http://www.b
Ianceng.cn/programming/java/201410/45828.htm System.out.println (Session.get (User.class, "123"));
System.out.println (Session.load (User.class, "123")); } CATCH (objectnotfoundexception e) {System.out.println ("the Load method throws Objectnotfoundexcep
tion anomaly ");
} System.out.println ("\ n \ nthe"); Verify that load returns the entity class object, not the proxy object {User User1 = (user) Session.get (user.class, "4028981b41174a69014
1174a6c6d0003 ");
User User2 = (user) session.load (user.class, "4028981b41174a690141174a6c6d0003");
System.out.println ("user1:" + user1.getclass (). Getsimplename ());
System.out.println ("User2:" + user2.getclass (). Getsimplename ());
System.out.println ("User1 and User2 are the same object:" + user1.equals (user2));
} System.out.println ("\ n \ nthe");
Session.clear ()//clear session//validation get can also return proxy class object, not necessarily return entity class object The Get method is also validated to find the slowSave (if no SQL statement is output, then get lookup cache) {User User3 = (user) session.load (user.class, "4028981b41174a69
0141174a6c6d0003 ");
User User4 = (user) Session.get (user.class, "4028981b41174a690141174a6c6d0003");
System.out.println ("User3:" + user3.getclass (). Getsimplename ());
System.out.println ("User4:" + user4.getclass (). Getsimplename ());
System.out.println ("User3 and User4 are the same object:" + user3.equals (user4));
Session.gettransaction (). commit ();
catch (Exception e) {e.printstacktrace ();
Session.gettransaction (). rollback ();
finally {hibernateutils.closesession (session); }
}
}
Run the result diagram:
There is also an interesting phenomenon:
User User5 = (user) session.load (user.class, "123");
System.out.println (User5.getid ());
Run Results Direct output 123
As you can see from the results, the first 2 lines of code do not perform database operations. Because the load will be in the first level of hibernate cache a map object, the map key is the value of the ID, but when you GetID (), it will go to the first cache to take map key value, just found, so no longer to execute database query. Nor do I report anything wrong. The results are as above.