Session, sessionfactory, configuration, transaction, query and criteria interfaces, and callback Interfaces

Session Interface

The session interface is the most important interface for hibernate developers. However, in hibernate, the instantiated session is a lightweight class, and it does not occupy a lot of resources when it is created or destroyed. This is really important in the actual project, because in the customerProgramThe Session object may be created and destroyed constantly. If the session overhead is too large, it will bring adverse effects to the system. However, it is worth noting that the session object is non-thread-safe. Therefore, in your design, it is best to create only one session object for one thread.

In the minds of hibernate designers, they regard sessions as an intermediate interface between data connection and transaction management. We can think of a session as a buffer for persistent objects. hibernate can detect changes to these persistent objects and refresh the database in time. We sometimes call session a persistent layer manager because it contains some persistence layer-related operations, such as storing persistent objects to the database and obtaining them from the database. Note that the hibernate session is different from the httpsession In the JSP application. When we use the term session, we refer to the session in hibernate, And we will later call the httsemi sion object a user session.

Sessionfactory Interface

Here we use a design mode-factory mode. The user program obtains the session instance from the factory class sessionfactory.

What surprised you is that sessionfactory is not lightweight! In fact, its designer's intention is to allow it to be shared throughout the application. Typically, only one sessionfactory is required for a project, but when your project needs to operate on multiple databases, you must specify one sessionfactory for each database.

Sessionfactory actually plays a buffer role in hibernate. It buffers the SQL statements automatically generated by Hibernate and some other ing data, and buffered some data that may be reused in the future.

Configuration Interface

The configuration interface is used to configure and start hibernate. During hibernate startup, the configuration instance first locates the ing document, reads the configurations, and creates a sessionfactory object.

Although the configuration interface only plays a very small role in the entire hibernate project, it is every object you encounter when starting hibernate.

Transaction Interface

The transaction interface is an optional API. You can choose not to use this interface and replace it with the underlying transaction processing written by the hibernate designer.Code. The transaction interface is an abstraction of the actual transaction implementation. These implementations include JDBC transactions, usertransaction in JTA, and even CORBA transactions. This design allows developers to use a unified transaction operation interface so that their projects can be easily moved between different environments and containers.

Query and criteria Interfaces

The query interface allows you to easily query databases and persistent objects. It can be expressed in hql or SQL statements of local databases. Query is often used to bind query parameters, limit the number of query records, and finally perform query operations.

The criteria interface is very similar to the query interface. It allows you to create and execute object-oriented standardized queries.

It is worth noting that the query interface is also lightweight and cannot be used outside the session.

Callback Interface

when some useful events occur, such as loading, storage, and deletion of persistent objects, the callback interface notifies hibernate to receive a notification message. Generally, the callback interface is not required in the user program, but you may use it when creating audit logs in your project.