Explain the basic implementation principle of Hibernate 4 in detail

Overall process

1: Read CFG through configuration XML file

2: Get sessionfactory factory

3: Create a session instance through the sessionfactory factory

4: Open transaction through session

5: Operate database through session API

6: Transaction commit

7: Close connection

Note: the implementation process described by the following sub methods is not the complete implementation process of hibernate, nor the complete implementation sequence of hibernate. It only describes the backbone and basic methods of hibernate to implement these methods, which is mainly used to understand what happens behind these methods. If you need a detailed and complete implementation process, please refer to the corresponding hibernate documents and source code

When we call session After saving (usermodel):

1: To - > Po: Hibernate searches the cache first. If it finds that a PO with the same ID already exists in the internal cache, it is considered that the data has been saved and an exception is thrown.

If there is no in the cache, hibernate will put the incoming to object into the instance pool controlled by the session, that is, turn a transient object into a persistent object.

If hibernate is required to generate the primary key value, hibernate will generate the ID and set it on the Po

2: The client commits a transaction or flushes memory

3: According to model type and CFG XML to find the corresponding HBM XML file

4: According to HBM XML file and model to dynamically spell SQL, as follows:

Insert into table name (from HBM. XML) (field name list (from HBM. XML)) values

5: Really use JDBC to execute SQL and add values to the database

6: Return the ID of this PO.

When we call session After update (usermodel):

1: Do - > Po: first, find the object in the hibernate instance pool according to the model's primary key, and throw an error when found.

If there is no do - > Po, hibernate will put the incoming do object into the instance pool controlled by the session, that is, turn a transient object into a persistent object

2: The client commits a transaction or flushes memory

3: According to model type and CFG XML to find the corresponding HBM XML file

4: According to HBM XML file and model to dynamically spell SQL without dirty data check, as follows:

Update table name (from HBM. XML) set field name (from HBM. XML) = value (get the value from the incoming model according to HBM. XML) where condition

5: Really use JDBC to execute SQL and modify the value to the database

When we call session After update (usermodel):

1: First, find the object in the hibernate instance pool according to the model's primary key, and use the Po object (used to check dirty data) when it is found.

2: The client commits a transaction or flushes memory

3: Hibernate will check the dirty data. If no data is modified, the following steps will not be performed.

4: According to model type and CFG XML to find the corresponding HBM XML file

5: According to HBM XML file and model to dynamically spell SQL and check dirty data (if dynamic update is enabled), as follows:

6: Really use JDBC to execute SQL and modify the value to the database

ID generation method is assigned

When we call session After delete (usermodel):

1: Find data in the database according to the model's primary key to ensure the existence of the object, and then put the found object into memory. If the corresponding entity object already exists in the hibernate instance pool (Note: the proxy object is not an entity object), an exception will be thrown.

2: If there is no corresponding entity object in the hibernate instance pool at this time, the object will be put into memory, but it will be identified as an object to be deleted and can not be used by load, etc.

3: If the object still does not exist, it will be returned directly (note that no exceptions will be thrown at this time). That is, a query statement will be executed before delete.

4: The client commits a transaction or flushes memory

5: Judge whether the Po to be deleted exists. It needs to be deleted only if it exists. Otherwise, it does not need to be deleted

6: If you want to delete, perform the following steps. First, according to the model type and CFG XML to find the corresponding HBM XML file

7: According to HBM XML file and model to dynamically spell SQL, as follows:

8: The real JDBC executes SQL and deletes the data from the database

ID generation method is not assigned

When we call session After delete (usermodel):

1: Find the corresponding entity object in the hibernate instance pool according to the model's primary key (Note: the proxy object is not an entity object), and throw an exception if found.

2: If there is no corresponding entity object in memory, nothing will be done.

3: The client commits a transaction or flushes memory

4: First, according to the model type and CFG XML to find the corresponding HBM XML file

5: According to HBM XML file and model to dynamically spell SQL, as follows:

6: Really use JDBC to execute SQL and delete the data from the database. If the data does not exist, an exception will be thrown

When we call session After delete (usermodel):

1: According to the model's primary key, find the corresponding entity object in the hibernate instance pool (Note: the proxy object is not an entity object), and use the object when found.

2: If there is no corresponding entity object in memory, search in the database to ensure the existence of the object. The found object is placed in memory and will not be identified as an object to be deleted. It can continue to be used by load, etc. Proxy objects also need to find data in the database.

3: If the object still does not exist, an exception is thrown. In other words, a query statement may be executed before delete.

4: The client commits a transaction or flushes memory

5: According to model type and CFG XML to find the corresponding HBM XML file

6: According to HBM XML file and model to dynamically spell SQL, as follows:

7: Really use JDBC to execute SQL and delete the data from the database

When we call s.Load (usermodel. Class, "primary key value"); after:

1: Find an object in the L1 cache according to the model type and primary key value, and return the object when it is found

2: If not found, judge whether lazy = true. If yes, generate a proxy object and return it; Otherwise, look for the L2 cache first. If there is no L2 cache, look for the database. If the proxy object is returned, when accessing the non primary key attribute for the first time, first search the L2 cache. Only when there is no in the L2 cache can the database be really searched.

3: If you need to find the database, it will be based on the model type and CFG XML to find the corresponding HBM XML file

4: According to HBM XML file and model to dynamically spell SQL, as follows:

5: Really use JDBC to execute SQL and query the data from the database to rs. If you can't find it, report an error

6: From the result set -- > model, and then return model

Note: the load method can execute query statements regardless of the transaction.

When we call s.get (usermodel.class, "primary key value"); after:

1: First, find the cache according to the model type and primary key value. If there is a specific entity object, return it; If there is a proxy object for the entity (for example, if the previous data is loaded but not used, then load generates a proxy object with only a primary key value). Then find the database, fill the specific data into the proxy object, and then return the proxy object. Of course, the proxy object has completely loaded the data at this time, which is no different from the entity object.

2: If you want to find the database, first according to the model type and CFG XML to find the corresponding HBM XML file

3: According to HBM XML file and model to dynamically spell SQL, as follows:

Select field list (from HBM. XML) from table name (from HBM. XML) where primary key = value

4: Really use JDBC to execute SQL, query the data from the database to RS, and return null if there is no value

5: From the result set -- > model, and then return model

Note: the get method can execute query statements without opening transactions.

When we call q.list(); After:

1: Carry out semantic analysis on HQL and analyze the model

2: According to model type and CFG XML to find the corresponding HBM XML file

3: According to HBM XML file and model to parse HQL, so as to dynamically convert HQL into corresponding SQL. (the process from HQL to SQL is very complex, which not only distinguishes different databases, but also includes automatic optimization of SQL). Here can only be a simple example as follows:

4: Really use JDBC to execute SQL and query the data from the database to rs

5: From the result set -- > model set (or object array), and then return the model set (or object array)

Note: the list () method can execute query statements without opening transactions.

summary

The above is the basic implementation principle of hibernate4 introduced by Xiaobian. I hope it will help you. If you have any questions, please leave me a message, and Xiaobian will reply to you in time. Thank you very much for your support for the programming tips website!