Session in hibernate

Session in hibernate

 

1. Master Configuration

 

◆ Query cache, which is different from the cache described below. It is a cache for hql statements, that is, cache data can be used for re-execution of identical statements. However, the query cache in a transaction system (data changes frequently and the probability of the same query conditions is not large) may be counterproductive: it will consume a lot of system resources in vain, but it is difficult to come in handy.

 

◆ Fetch_size: similar to JDBC-related parameters. The larger the parameter, the better. You should set it according to the business characteristics.

 

◆ Batch_size is the same as above.

 

◆ In the production system, remember to turn off SQL statement printing.

 

Ii. hibernate session cache

 

1. database-level cache: this level of cache is the most efficient and secure, but different database management levels are not the same. For example, in Oracle, you can specify to cache the entire table during table creation.

 

2. session cache: effective in a hibernatesession. This level of cache is not reliable and is more efficient than hibernate's automatic management. However, it provides a method to clear the cache, this is effective in bulk Add/update operations. For example, if you add 100,000 records at the same time, you may find an outofmemeroy exception. In this case, you may need to manually clear the cache: Session. evict and session. Clear.

 

3. application cache: it is effective in a sessionfactory, so it is also the top priority of optimization. Therefore, there are many policies to consider. Before putting data into this level of cache, you need to consider the following prerequisites:

◆ Data will not be modified by a third party (for example, is there another application that is also modifying the data ?)

◆ Data is not too big

◆ Data will not be updated frequently (otherwise, using the cache may be counterproductive)

◆ Data is frequently queried

◆ Data is not key data (such as money and security issues ).

 

Hibernate session cache can be configured in several forms in the ing file: Read-Only (read-only, applicable to static/historical data with few changes), nonstrict-read-write, read-write (common format with average efficiency), transactional (in JTA, few caching products are supported)

 

4. distributed cache: Same as 3) configuration, but the selection of cache products is different. Currently, there are not many options available in hibernate, such as Oscache and JBoss cache. Most of the current projects, they are conservative in using clusters (especially key transaction systems. In a cluster environment, database-level cache is the safest.

 

Iii. Delayed Loading

◆ Object delayed loading: implemented through dynamic proxy

◆ Set delayed loading: hibernate provides support for this by implementing its own set/list.