Session usage in hibernate:
In hibernate, sessions are mainly used to operate databases?
Hibernate needs to obtain the session instance before operating the database, which is similar to the connection in JDBC.
The method for obtaining a session is as follows:
Session session = sessionfactory. opensession ();
The Session object can be used to add, delete, modify, and query databases. The corresponding methods are: Save (), delete (), update (), saveorupdate (), load (), get ().
In hibernate 3, the find () method is canceled and must be queried through query or criteria.
The learning of the session interface is the most painful and complex, because it involves too many aspects and many hidden mechanisms. Who makes it a central API.
It takes me some time to learn several basic methods, such as Save (), delete (), and flush. Before learning about these methods, it is helpful to understand the session cache mechanism and the status of Java objects in hibernate.
I. session cache
Java is a pure object-oriented language, so it is impossible to directly manipulate the memory like the C language, such as declaring a piece of available memory space. In Java, cache usually refers to the memory space occupied by Java object attributes, which are usually set attributes. The sessionimpl implementation class of the session interface defines a series of Java sets, which constitute the session cache.
One obvious advantage of using the cache is that it can reduce the frequency of database access and improve the performance of applications, because reading data from the memory is obviously much faster than querying from the database. According to my personal understanding, session cache actually acts as a "transition repository. Just like a hero in Warcraft, there will be a bag on his body to store frequently used items such as blood potion, magic potion, and warehouse roll. If you want to use a return volume without a return volume, you have to go to the store to shopping. This will waste a lot of time, unless you are at the store now; if you want to use the app, you can use it directly without having to go to the store. The cache of our session can be said to be equivalent to a backpack on a hero. My application is a hero, and the database is a store.
Of course, this metaphor is not very accurate. For example, in the hibernate application, We can insert a new record into the database, and in Warcraft, you cannot increase the inventory for the store, this comparison was made only for ease of understanding.
Ii. Status of Java objects in hibernate
In a hibernate application, Java objects can be in one of the following three States:
1. temporary status (transient ). Objects in this state have not been incorporated into the Cache Management System of hibernate, and are not associated with any session, and there is no corresponding record in the database.
2. Persistent ). The object in this state is located in the session cache and corresponds to a data record in the database.
3. detached ). An object in this state is no longer in the session cache. The biggest difference between it and a temporary object is that a free object may have a record corresponding to it in the database.
The preceding three states can be converted to each other, and the state we call is for a session instance. For example, object A is persistent for session1, because it is in the cache of session1, but for session2, object A is not in its cache, so it is in the Free State.
It takes me some time to understand these statuses, because there are always some strange thoughts in my mind. For example, for the definition of a temporary state, if I create an object, and then manually make the attribute value correspond to a record in the database, including the id value. Can it be said that it is in a free state? Because it corresponds to a record. In fact, these situations are caused by some non-standard operations. In hibernate applications, no matter the Java object is in the temporary, persistent, or free state, the application should not modify its oid. The OID value should be maintained and responsible by hibernate. In fact, when hibernate synchronizes the objects in the cache with the records in the database, it uses OID for association and ing, if the application manually modifies the object's OID, it will lead to some inexplicable errors, and this is not conducive to data synchronization.
About session [reprinted]