Application of delayed loading mechanism of database, cache management

One
1. Delayed loading
Lazy loading is a mechanism that hibernate provides to improve program execution efficiency, which is created only if the object's data is actually used.
Occasion one: When a user wants to fetch a field from a table in a database, this field is likely to be a character, with a short length.

Scenario Two: When the user wants to fetch the value of a field in a table of a database, and this value is likely to be a blob type, perhaps access is a very large video file.

Is it the same way of fetching data in two situations? Is it a load or a Get method?


Deferred loading: A deferred load is implemented through the proxy mechanism. Hibernate does not load real data from a database when it obtains an object's data from the database, gets the collection property value of an object, or gets another object associated with an object, because no data is used for that object (except for identifiers). Instead of just creating a proxy object for the object to represent the object, all the properties on that object are the default values, and the real object is created only when the object's data is really needed, actually loading its data from the database.

Lazy Loading of objects
Lazy loading of properties in objects
Collection Lazy Loading


Account acc= Session.load (account.class,new Long (1)); Returns a proxy object
System.out.println (Acc.getid);
System.out.prontln (Acc.getlonginname ());

This lazy loading is useful when only one reference to the account class is required.



It is not necessary to initialize the code if you simply access the object identifier property.
Account acc= Session.load (account.class,new Long (1)); Returns a proxy object
Order order=new order ();
Order.setcreatetime (New Date ());
Order.setaccount (ACC);
Session.save (order);
In this case, only the account instance is required to create a new Order object, and when Session.save (order) is called, only the primary identifier value of the account is saved to the corresponding field in the order table as a foreign key. This results in less execution of a SELECT statement, which improves query efficiency.


Lazy loading is the default feature in Hibernate for the following reasons:
Lazy loading is used when the load () method on the session is called to load an entity.
When a session loads an entity, deferred loading is applied to the value of the collection attribute in the entity. (One-to-many)
When a session loads an entity, a deferred load is applied to another entity object that is a single-ended association (one-to-one, Many-to-one) for that entity.

Lazy-loaded objects are rewritten proxy objects, and when the associated session is not closed, access to the properties of these lazy-loaded objects (except GetID and GetClass) hibernate initializes the agents. or use Hibernate.initialize (proxy) to initialize the proxy object, and when the associated session is closed, then access the lazy loaded object will appear an exception.




2. Delay Load off
When loading a single entity, you can use the Get () method of the session if you do not need to delay loading.
When a session loads an entity, it does not need to delay loading the value of the collection attribute in the entity, but to load it immediately. The configuration element for this collection property can be used in the mapping file (<SET>,<BAG>,<LIST> ...). Add Property lazy= "false".

When the session loads an entity, there is no need to delay loading another entity object associated with the entity's single-ended, and it is possible to associate the configuration element in the mapping file with that single-ended (<one-to-one>,<many-to-one> Add Property lazy= "false".
Note: one-to-one cannot have constrained=true



Second, crawl strategy
Using a FETCH connection query in the HQL statement, the data from the associated two entities is loaded from the database one time by writing a LEFT JOIN FETCH statement. This can improve query efficiency by reducing the number of SQL in specific situations, which also require the use of data from both entities.

The query effect of the get () and load () methods of the session is directly affected by configuring the crawl policy.
1. Single-ended correlation <many-to-one><one-to_one> crawl strategy.
You can add a fetch attribute to a single-ended associated mapping element. Fetch attribute has 2 optional values
Select: As the default, its policy is to send a separate SELECT statement to fetch data for the associated object of the current object when it is necessary to use the data to the associated object. That is, lazy loading.
Join: Its strategy is to use a connection in the same SELECT statement to get the data of the object and the data of its associated object, at which time the deferred loading of the associated object is invalidated.



2. Fetch policy on collection properties
You can add a fetch attribute on a mapped element of a collection property, which has 3 optional values.
Select: As the default, its policy is to send a separate SELECT statement to fetch the associated collection of the current object when it is necessary to use the data of the associated collection, that is, lazy loading.
Join: Use a connection in the same SELECT statement to get the associated collection of each other. Lazy at this time on the associated collection is invalidated.
Subselect: Another query statement (or subquery) is sent to fetch the associated collection of all the entity objects previously queried. This policy also works on HQL queries.



When fetch is a join, the left outer join is performed, and at this time, when the customer is loaded, the order value corresponding to the customer is loaded into the cache, which is a good choice if there is no big data in the order.
When fetch is subselect, it is valid for in, and if select, from Customer where ID in (All-in-a-time), Hibernate takes the ID out and takes the order value individually, which is less efficient. This time the subselect is more efficient, no matter how much data in the in, the query order is, will only issue an SQL statement. Setting the Batch-size in the <set> collection to a more appropriate value is also equivalent to fetch as subselect, and you can choose the number of times to issue the SQL statement based on the project's factors.


HQL always ignores the pre-fetch policy set in the mapping file, that is, when using pre-fetching in HQL, the specified fetch keyword must be displayed. However, QBC does not ignore the pre-fetch policy in the mapping file.

In the process of practical development project, not only need to choose the appropriate crawl strategy according to the actual situation, but also need to pass the constant test to verify that this strategy is the most efficient.




Third, cache management
1. Caching Overview
Caching (cache) is a set of in-memory collection instances in a Java application. It holds a backup of data in a persistent storage source, such as a file on a hard disk or a database, and reads and writes faster than a hard disk. The application directly reads and writes data from the cache at run time, and only installs the data in the cache at certain moments to update the data storage source for the companion. If the amount of data stored in the cache is very large, the hard disk is used as the cached physical medium.
The role of caching is to reduce the frequency with which applications directly read and write to persistent data storage sources, thereby enhancing the operational performance of the application.
The implementation of the cache requires not only the hardware (memory) of the physical medium, but also the software that manages policies such as cache concurrency access and expiration.
2 Cache Range Classification
The scope of the cache determines the life cycle of the cache and who can access it. The scope of the cache falls into the following three categories:
1) Transaction scope: The cache can only be accessed by the current transaction. The life cycle of the cache relies on the life cycle of the transaction, and when the transaction ends, the cache ends the life cycle. Under this range, the cached media is memory.
2) Process scope: The cache is shared by all transactions within the process. These transactions are likely to be concurrent access caches, so a necessary transaction isolation mechanism must be taken against the cache.
3) Cluster scope: In a clustered environment, the cache is shared by the processes of a machine or multiple machines. The cached data is replicated to each process node in the clustered environment, and the data consistency in the cache is ensured through remote communication between processes. For most applications, cluster-wide caching should be used with caution because the speed of access is not necessarily much faster than accessing database data directly.
3. Cached concurrent access policies
Concurrency issues occur in a process-wide or cluster-wide cache. Therefore, you can set a concurrency access policy of type 4, with each policy corresponding to a transaction isolation level. The higher the isolation level of a transaction, the lower the concurrency performance.
1) transaction type (transactional) policy
2) Read-write (read-write) strategy
3) Non-strict read-write (nonstrict-read-write) strategy
4) Read-only (read-only) strategy


Cache in 4.Hibernate
Hibernate provides a level two cache, and the first level of cache is the session-level cache, which is a transaction-scoped cache.
The second level of caching is the cache at the sessionfactory level, which is a process-scoped cache that can be configured and changed, and can be dynamically loaded and unloaded.
Hibernate also provides a query cache for query results, which relies on level two caching.




5. Management of first-level caches
Session-level caching is automatically managed by hibernate. When the application calls the session's Crud method and invokes the query interface's list (), iterate (), and so on, hibernate will add the object to the session cache if there are no corresponding objects in the session cache. If the object already exists in the session cache, it does not need to go to the database to load but directly use the object in the cache, which can reduce the frequency of accessing the database and improve the running efficiency of the program. When hibernate cleans up the cache (by default, the transaction is committed), hibernate synchronizes the data state in the database based on the state of the objects in the cache, and when the session is closed, all objects in the session cache are emptied.



The first-level cache does not control the number of caches, so be aware that large batches of data can cause memory overflow;
Evict (Object obj): Clears the specified persisted object from the cache.

Clear (): Empties all persisted objects in the cache.

Flush (): Performs an operation that cleans up the cache (where the data in the cache is not lost), and lets the cache and database synchronously execute some column SQL statements without committing the transaction.

Commit (): First call the Flush () method and then commit the transaction. means committing a transaction means permanently saving the database operation.



Can write a for loop, session can be BULK insert tens of thousands of data. As in the following code:
for (int i=0;i<10000;i++) {
Session.save (object);
}
What is the problem with writing this code? Makes the cache of 10,000 objects all present in memory, which increases the pressure on the memory. Therefore, the session cache should be cleaned up periodically.
As a BULK INSERT or batch update, you must control the size of the first-level cache by calling flush () of the session and later by calling clear (), so that the memory is guaranteed enough space.



for (int i=1;i<=50;i++) {
Department Dept = new Department ();
Dept.setname ("Software" +i);
Session.save (dept);
for (int j=1;j<=100;j++) {
Employee EMP = new Employee ();
Emp.setname ("Zhang San" +j);
Emp.setsalary (j);
Emp.setdept (Dept
Session.save (EMP);
if (j%50==0) {
Session.flush ();
Session.clear ();
}
}
}
6. Management of Level two cache
The second-level cache is the sessionfactory level of caching, and it uses the following procedures:
1) When performing a conditional query, issue a SQL statement such as "SELECT * FROM table_name where ..." to query the database and get all the data objects at once.
2) Put all the obtained data objects into the level two cache based on the ID.
3) When hibernate accesses the data object based on the ID, it is first checked from the session cache, and if a level two cache is configured, it is checked from the two cache, and the database is queried, and the results are placed in the two level cache by ID.
4) When deleting, updating, and adding data, it will be updated to the level two cache.
Hibernate's level Two cache policy is a cache policy for ID queries and is not useful for tuning queries. To do this, hibernate improves the query cache for conditional queries alone.


The data that is suitable for storage in level two cache are:
1) data that is rarely modified.
2) data that is not very important, allowing occasional concurrent data to occur.
3) Many system modules need to be used
4) Not private data, is shared

What kind of data does not fit in the level two cache???
Data security for financial data is the data that you don't want to see and the data that's especially important.
1, level two cache management
The second-level cache is the sessionfactory level of caching, and it uses the following procedures:
1) When performing a conditional query, issue a SQL statement such as "SELECT * FROM table_name where ..." to query the database and get all the data objects at once.
2) Put all the obtained data objects into the level two cache based on the ID.
3) When hibernate accesses the data object based on the ID, it is first checked from the session cache, and if a level two cache is configured, it is checked from the two cache, and the database is queried, and the results are placed in the two level cache by ID.
4) When deleting, updating, and adding data, it will be updated to the level two cache.
Hibernate's level Two cache policy is a cache policy for ID queries and is not useful for tuning queries. To do this, hibernate improves the query cache for conditional queries alone.

The data that is suitable for storage in level two cache are:
1) data that is rarely modified.
2) data that is not very important, allowing occasional concurrent data to occur.
3) Many system modules need to be used
4) Not private data, is shared

What kind of data does not fit in the level two cache???
Data security for financial data is the data that you don't want to see and the data that's especially important.

2. Query cache
You can enable query caching if you are using the same criteria values for queries in your actual use for a conditional query statement.
The process of Hibernate's query caching policy is as follows.
1) When performing a conditional query for the first time, hibernate first consists of a query Key,query key that includes the request information for the conditional query based on these criteria values.
2) in the subsequent process with the same condition value to execute this query is, hibernate first based on this query key to the search cache to find the corresponding result list, if present, return. If it does not exist, check the database, and then the results list can be stored in the query cache according to queries.
Therefore, you can benefit from the query caching strategy only if you frequently use the same parameter values for the same conditional query.


Steps for using query caching
1. Configure the query cache
Hibernate provides 3 cache areas that are related to queries.
Default Query cache area: Org.hibernate.cache.StandardQueryCache
User-defined query cache area
Timestamp Cache area: Org.hibernate.cache.UpdateTimestampCache

Set the properties of the query cache area in Ehcache configuration file ehcache.xml.

<ehcache>
<!--set properties of the default query cache area--
<cache name= "Org.hibernate.cache.StandardQueryCache"
maxelementsinmemory= "50"
Eternal= "false"
Overflowtodisk= "true"
timetoidleseconds= "3600"
timetoliveseconds= "7200"
/>

<!--setting properties of the timestamp cache area--
<cache name= "Org.hibernate.cache.UpdateTimestampsCache"
maxelementsinmemory= "500"
Eternal= "true"
Overflowtodisk= "true"
/>

<!--setting properties of a custom named query cache area-
<cache name= "Mycacheregion"
maxelementsinmemory= "1000"
Eternal= "false"
Overflowtodisk= "true"
timetoidleseconds= "3600"
timetoliveseconds= "7200"
/>
</ehcache>
3.

Open Query Cache
In Hibernate's global configuration file, add the following configuration to start the query cache.
<!--enable query caching--
<property name= "Cache.use_query_cache" >true</property>

Using query caching in application code
Although the query cache is set up as above, Hibernate ignores the query cache by default when executing a conditional query. If you want to enable query caching, you should call the Setcacheeable (True) method of the query interface.

Application of delayed loading mechanism of database, cache management