Session interface
The session interface is one of the most important interfaces for hibernate developers. In hibernate, however, the instantiated session is a lightweight class, and creating and destroying it does not consume a lot of resources. This is really important in the actual project, because in the client program, the session object may be created and destroyed continuously, if the session overhead is too large, it will adversely affect the system. However, it is important to note that the session object is non-thread safe, so in your design it is better to have a thread that creates only one session object.
In the minds of hibernate designers, they regard the session as a middle interface between data connection and transaction management. We can think of the session as a buffer of persistent objects, hibernate detects changes to these persistent objects, and refreshes the database in a timely manner. We sometimes call the session a persistent Layer manager because it contains some persistent layer-related operations, such as storing persistent objects to the database, and getting them from the database. Note that Hibernate's session differs from HttpSession in JSP applications. When we use the term session, we are referring to the session in Hibernate, and we will later refer to the Httpsesion object as the user session.
Sessionfactory interface
Here is a design pattern-factory mode, where the user program obtains an instance of the session from the factory class Sessionfactory.
What makes you wonder is that sessionfactory is not lightweight! In fact its designer's intention is to allow it to be shared throughout the application. Typically, a project usually requires only one sessionfactory, but when your project is working on multiple databases, you must specify a sessionfactory for each database.
Sessionfactory actually played a buffer in hibernate, buffering hibernate's automatically generated SQL statements and some other mapping data, and buffering some data that might be reused in the future.
Configuration interface
The purpose of the configuration interface is to configure Hibernate and start it. During Hibernate startup, an instance of the configuration class first locates the location of the mapped document, reads the configuration, and then creates a Sessionfactory object.
Although the configuration interface plays only a small role throughout the Hibernate project, it is the object that you encounter when you start hibernate.
Transaction interface
The transaction interface is an optional API, and you can choose not to use this interface instead of the underlying transaction code written by Hibernate's designers themselves. The transaction interface is an abstraction of the actual transaction implementation, which includes JDBC transactions, usertransaction in Jta, and even CORBA transactions. This design is designed to enable developers to use a single transactional interface, allowing their projects to easily move values between different environments and containers.
Query and Criteria Interface
The query interface makes it easy to make queries against databases and persistent objects, which can be expressed in two ways: the HQL language or the SQL statement for the local database. Queries are often used to bind query parameters, limit the number of query records, and ultimately perform query operations.
The criteria interface is very similar to the query interface, which allows you to create and execute object-oriented, standardized queries.
It is important to note that the query interface is also lightweight and cannot be used outside the session.
Callback interface
The callback interface notifies hibernate to receive a notification message when a useful event occurs-for example, when a persistent object is loaded, stored, or deleted. In general, the callback interface is not required in a user program, but you might use it when you want to create an audit log in your project.
Sessionfactory,session's understanding in Hibernate?