Hibernate frame Learning Level cache

The cache is a temporary space for storing data, reducing the number of times the data is queried from the database

There are two kinds of caching mechanisms available in Lhibernate

? First level cache (hibernate itself carries)

? level two cache (using external technology)

The first-level cache of Lhibernate is the temporary data storage area in which hibernate operates data, which is bound to the session object, that is, each time a session object is opened, a corresponding level of cache space is generated, and when the session object is closed, The data in this space, which is the PO object that is saved, is converted into a Do object.

The first level cache of Lhibernate is the session level cache, which corresponds to session object one by one, and the cache data cannot be shared between sessions.

L Verify the existence of hibernate first-level cache

The difference between the Lget and the Load method

? Same: Load and get method query data, first look for the existence of a primary cache to find the data, if present, directly get, if not, from the database through the SQL statement to get the data of the database side

Different: The Load method queries to the object, if only the OID of the data will not make any query, directly return the OID, if you need to use data other than OID, then follow the above rules to find the corresponding data

L Configure to turn off lazy load--lazy properties

Hibernate lazy load on and off

L in the map file. hbm.xml file, you can configure whether to use the lazy load attribute, which can be configured in three locations

Hibernate uses first-level caching

Lhibernate's first-level cache can be understood as a transit point for data

Lhibernate the Data R operation

? If the data exists in the first-level cache, it is removed directly using the

? If the first-level cache does not exist, execute SQL statements are fetched from the database

Lhibernate for data cud operations

? Put the data and operation mode to be manipulated into a first-level cache

? Refresh the first-level cache to detect if persistence is required

Hibernate first-level cache refresh mode

The first-level cache of Lhibernate holds all the data in the session operation, which is submitted to the database for synchronous update, and executes the corresponding SQL statement for the data that needs to be updated.

? performing a transaction submission

? T.commit ();

Refresh cached data for session scope

? S.flush ();

? Close session

? S.close ();

Hibernate refreshes the first-level cache--Snapshot

When any data enters Hibernate cache, a clone (snapshot) of the data is saved immediately, and when the first cache is refreshed, the objects in each cache are compared, and if the snapshot data is the same as the current data, there is no action, if the snapshot data is different from the current data, Updates the modified data to the database, executes the corresponding SQL statement, and updates the snapshot data

The objects stored in the buffer are all PO, so the PO can update the database correspondence, and to and do have no such ability

L Refresh First Level cache

? S.flush ();

L Clear Cache level

? S.clear ();

L CLEAR the specified object in the first level cache

? s.evict (obj);

Updates the specified object in the first-level cache (overwrites a level of cache data and snapshot data with data in the database)

? S.refresh (obj);

Hibernate first-level cache refresh Time

L so-called Hibernate first-level cache refresh time refers to when the modification data that exists in the primary cache is synchronized to the database table

L There are four kinds of usual refresh time (Flushmodel constants)

? Always: Any action results in a refresh (low efficiency)

? AUTO: Whether to refresh (default) based on Operation function

? Commit: Refresh when committing a transaction

? MANUAL: Refresh on manual Refresh (session closed does not trigger)

L Set the way:

? S.setflushmode (Flushmode.commit);

? Set after the session object gets

Hibernate first-level cache common operations considerations

Lsave ()

Lupdate ()

Lmerge ()

Lsaveorupdate ()

Lget ()/load ()

Ldelete ()

The lsave operation can convert one to PO

L Operation Steps:

? loading to Session,to→po

? Use the ID generator to assign a unique identity oid to a PO

? If the OID is manually given, the generator will replace this OID with the configuration

? Add an INSERT statement to the execution plan to add the property values from the object to the INSERT statement through the configuration in the mapping file

L Note:

? To convert to PO after the save operation, if the OID of PO is modified, then an error will be generated, notifying the user that a PO's OID has changed, which is not allowed

Lupdate operation to convert a do to PO

L Operation Steps:

? Specify Oid,to→do for one to

? update Do,do→po by using update

? Add an UPDATE statement to the execution plan to add the property values from the object to the UPDATE statement by using the configuration in the mapping file

L Note:

? The Do conversion PO is completed with the UPDATE statement, and if a property update is made to the PO after conversion is complete, only one UPDATE statement will be generated, and the PO status change will complete the final operation when the cache is refreshed, unless the cache is refreshed in advance

? PO updates do not use the UPDATE statement and are automatically completed when the cache is refreshed

Lupdate will force the DO→PO operation to complete an update operation, regardless of whether the data has changed, at this time can be selected according to business needs

? If the user data is not changed, the UPDATE statement is not executed

? If the user data has changed, execute the UPDATE statement

The prerequisite for doing this is to compare the data of the update operation with the data in the database, i.e. execute the query statement select before the update operation, which can be done by configuration

? Configure select-before-update in the class element, default false for this configuration value

?

Note: When this setting is turned on, the overall efficiency will be reduced and chosen carefully.

After the lupdate operation converts do to a PO, it eventually executes the corresponding UPDATE statement to persist the data to the database, and the program will error if there are no data for the OID in the database table.

? The error is attributed to a basic SQL operation, and the SQL statement updates an operation that does not exist that will result in 0 rows of data affecting it, and for hibernate to attribute this behavior to an impossible task, eventually presenting it to the developer in the form of an exception

For example: A user read a piece of data, ready to modify the data, at this time B users delete this data, a user when modifying the data, the data has disappeared, resulting in the occurrence of the above problems, the latter can be configured to avoid the occurrence of this phenomenon, but the efficiency is very low. In the actual business, only need to give the user a reasonable hint on the line.

The lupdate operation can convert do to PO, but if there is a PO object with the same OID in the session scope, an error is displayed

L Summary: Any time, the same session range, regardless of the way, if two PO has the same OID, then hibernate can not distinguish two objects, this will be an error

When the lupdate operation converts do to PO, the program will error if there is a PO with the same OID in the session range. If you want to convert do to PO, you can combine two objects into one, and you can use the merge operation to complete the merging of objects.

The Lmerge action is to merge the Do property of the current operation onto the same PO as the OID, and the final attribute is subject to the last modification. If there is no PO with the same OID as do, the merge operation will perform the update operation and convert do to PO

Po,do Merge attribute to PO with same OID

Po,do converted to PO without the same OID

S.merge (UM);

Lsaveorupdate actions are performed according to the state of the object

? To perform a save operation

? PO without any action

? Do update operation

L Note: The criteria for determining to

? The OID of the object is null

In the Hbm.xml file, specify the value of the Unsaved-value property for the ID element, and the value of the OID of the object is the same as

Both the Lget and the load methods can obtain corresponding record information from the database based on the OID value passed in, and convert to PO

Lget load policy differs from load read (explained earlier)

The difference between lget and load gets data:

? Returns NULL when the OID data obtained by the get operation does not exist in the DB

When the OID data obtained by the load operation does not exist in the DB, the exception is thrown

The Load method does not return a model object, but a proxy object for the model object, so the final decoration cannot be used for the model class, otherwise the proxy object cannot be created

Ldelete action to delete a corresponding record from a database table

Operating principle of ldelete operation

The delete operation can only operate on a PO when it deletes an object

If do, first associated to session, convert do to PO

? To cannot delete

Perform a delete operation to add a delete tag to the deleted data within the session scope, at which point the object has been marked as deleted, but the DELETE statement has not been executed and the record is still present in the database

? When refreshing the cache, execute a real DELETE statement

Hibernate frame Learning Level cache