Hibernate (Open source Object Relational mapping framework)

Hibernate is an open source object-relational mapping framework that provides JDBC with a very lightweight object encapsulation, which speaks of pojo mapping with database tables, is a fully automated ORM framework, hibernate can automatically generate SQL statements, automatically execute, Enables Java programmers to manipulate databases using object programming thinking at will. Hibernate can be applied to any use of JDBC, both in Java client programs and in servlet/jsp Web applications, and most revolutionary: Hibernate can replace CMP in the EE architecture of the EJB application. The task of achieving data persistence.

Core interfaces and classes

There are 6 core classes and interfaces for hibernate: Session, Sessionfactory, Transaction, Query, criteria, and configuration. These 6 core classes and interfaces are useful in any development, and through these interfaces, you can not only persist objects for access, but also enable transaction control.

Session: The interface is responsible for performing crud operations on persisted objects (the task of crud is to complete the communication with the database, including many common SQL statements.) However, it is important to note that the session object is non-thread-safe. At the same time, Hibernate's session differs from the HttpSession in JSP applications. When the term "session" is used, it actually refers to the session in Hibernate, and later the HttpSession object becomes the user session.
sessionfactory : The Sessionfactory interface is responsible for initializing hibernate. It acts as a proxy for the data storage source and is responsible for creating session objects. The factory model is used here. It is important to note that Sessionfactory is not lightweight. Because in general, a project requires only one sessionfactory to be sufficient. When you need to manipulate multiple databases, you can specify a sessionfactory for each database.
Transaction: The Transaction interface is an optional API that allows you to opt out of using this interface instead of the underlying transaction code written by Hibernate's designers themselves. The transaction interface is an abstraction of the actual transaction implementation, which includes JDBC transactions, usertransaction in Jta, and even CORBA transactions. This design is designed to enable developers to use a unified transaction interface, so that their projects can be easily ported between different environments and containers. The
Query : Query interface makes it easy to query a database persistence object, which can be expressed in two ways: the HQL language or the SQL statement for the local database. Query is often used to bind queries to parameters. Limit the number of query records and ultimately perform query operations

Criteria: The criteria interface is very similar to the query interface, allowing you to create and execute object-oriented, standardized queries. It is important to note that the criteria interface is also lightweight and cannot be used outside the session.
Configuration: The purpose of the configuration class is to configure Hibernate and start it. During Hibernate startup, the power of the configuration class first locates the location of the mapped document, reads the configuration, and then creates a Sessionfactory object. Although the configuration class plays only a small role throughout the Hibernate project, it is the first object encountered when starting hibernate.

Introduction to primary keys
Assigned
The assigned method generates a primary key value by the user and will throw an exception if it is specified before save ()
Feature: The generated value of the primary key is determined entirely by the user, regardless of the underlying database. The user needs to maintain the primary key value and specify the primary key value before calling Session.save ().
Hilo
Hilo uses a high-low algorithm to generate a primary key, and the low-level algorithm uses a high value and a low value, and then stitching together the two values of the algorithm as the unique primary key in the database. The Hilo approach requires additional database tables and fields to provide high-level value sources. The table used by default is
Hibernate_unique_key, the default field is called Next_hi. Next_hi must have a record otherwise an error will occur.
Features: Additional database table support is required to guarantee the uniqueness of the primary key in the same database, but it does not guarantee the uniqueness of the primary key between multiple databases. The Hilo primary key generation method is maintained by hibernate, so Hilo is not independent of the underlying database, but should not manually modify the values of the tables used by the Hi/lo algorithm, or it will cause duplicate exceptions for the primary key.

Increment
The increment method generates a new primary key value by automatically increasing the primary key value, but requires that the primary key type of the underlying database be a numeric type such as Long,int. The primary key is incremented in numerical order, and the increment is 1.
/ Features: Maintained by hibernate itself, suitable for all databases, not suitable for multi-process concurrent update database, suitable for a single process to access the database. cannot be used in a clustered environment. /

Identity
The identity method supports automatic growth based on the underlying database, and different databases use different primary key growth modes.

Features: Related to the underlying database, requires the database to support identity, such as MySQL is auto_increment, SQL Server is identity, the supported databases are MySQL, SQL Server, DB2, Sybase and Hypersonicsql. The identity does not require hibernate and user intervention, it is easier to use, but it is not easy to migrate programs between different databases.

Sequence
Sequence requires the underlying database to support sequence methods, such as Oracle database, etc.

Features: The support sequence of the underlying database is required, the database that supports the sequence has DB2, POSTGRESQL, Oracle, sapdb, and so on, porting programs between different databases, especially from the database that supports the sequence to the database that does not support the sequence, the configuration file needs to be modified.

Native
The native primary key generation method automatically selects the identity, Sequence, and Hilo primary key generation methods based on different underlying databases

Features: Depending on the underlying database, different primary key generation methods are used. Because Hibernate uses different mapping methods based on the underlying database, it is easy to migrate programs, which can be used if multiple databases are used in a project.

UUID
The UUID uses the 128-bit UUID algorithm to generate the primary key, which can guarantee the uniqueness of the primary key under the network environment, and can guarantee the uniqueness of the primary key under different database and different server.

Features: can guarantee the uniqueness of the primary key in the database, the generated primary key occupies more storage space

Foreign GUID
Foreign is used in a one-to-one relationship. The GUID primary key generation method uses a special algorithm that guarantees the uniqueness of the generated primary key and supports SQL Server and MySQL

The role of the package

net.sf.hibernate.* [1]

The class of the package is basically the interface class and the exception class

Net.sf.hibernate.cache.*

Implementation class of JCS

net.sf.hibernate.cfg.*

Configuration file Read class

net.sf.hibernate.collection.*

Hibernate collection interface implementation classes, such as List,set,bag, and so on, hibernate to write its own collection interface implementation class is to support the lazy loading

net.sf.hibernate.connection.*

Provider of several database connection pools

net.sf.hibernate.dialect.*

supports a variety of database features, each dialect implementation class represents a database that describes the data types and other features that the database supports, such as whether there are autoincrement, whether there are sequence, whether there are paging SQL, etc.

Net.sf.hibernate. eg.*

Examples used in Hibernate documentation
net.sf.hibernate.engine.*
The class function of this package is relatively scattered
net.sf.hibernate.expression.*

HQL Supported expressions

net.sf.hibernate.hq.*

HQL implementation

Net.sf.hibernate. id.*

ID Generator

Net.sf.hibernate.impl.*

The core of the package, some important interfaces of the implementation class, such as Session,sessionfactory,query, etc.

Net.sf.hibernate.jca.*

JCA support, wrapping the session as a JCA-enabled interface implementation class

net.sf.hibernate.jmx.*

JMX is used to write the hypervisor of the app server, presumably the implementation of the JMX part of the interface, allowing app server to manage hibernate through the JMX interface

Net.sf.hibernate.loader.*

is also the core of the package, mainly the generation of SQL statements

net.sf.hibernate.lob.*

Blob and CLOB support

net.sf.hibernate.mapping.*

The properties of HBM files are implemented

Net.sf.hibernate.metadata.*

The meta implementation of PO

net.sf.hibernate.odmg.*

ODMG is an ORM standard, this package is the ODMG standard implementation class

Net.sf.hibernate.persister.*

Core packages for mapping between persistent objects and tables

Net.sf.hibernate.proxy.*

Proxy and lazy loading support

Net.sf.hibernate. ps.*

The package is preparedstatment Cache

Net.sf.hibernate.sql.*

The package that generated the JDBC SQL statement

net.sf.hibernate.test.*

Test class, you can use JUnit to test hibernate

net.sf.hibernate.tool.hbm2ddl.*
Generating DDL with HBM configuration files

net.sf.hibernate.transaction.*

Hibernate Transaction Implementation Class

Net.sf.hibernate.type.*

Data type for properties of persisted objects defined in hibernate

Net.sf.hibernate.util.*

Some tool classes, the role of a more scattered

Net.sf.hibernate.xml.*

XML Data Binding

Cache Management

Hibernate provides a level two cache (cache), and the first level of cache is session-level caching, which is a transaction-scoped cache. This level of caching is managed by Hibernate, and generally does not require intervention; the second level of caching is the cache at the sessionfactory level, which is a process-wide or cluster-wide cache. This level of caching can be configured and changed, and can be dynamically loaded and unloaded.  Hibernate also provides a query cache for query results, which relies on a second-level cache. First-level cache the second-level cache holds the data in the form of a scoped transaction scope for the bulk data cache of the persisted object, each transaction has a separate first-level cache process scope or cluster scope, and the cache is shared by all transactions within the same process or cluster for concurrent access policies because each transaction has a separate first-level cache , there is no concurrency problem and there is no need to provide concurrent access policies because multiple transactions access the same data in the second level cache at the same time, the appropriate concurrency access policy must be provided to ensure that a specific transaction isolation level data expiration policy does not provide a data expiration policy. Objects in the first-level cache never expire unless the application explicitly empties the cache or clears the specific object must provide a data expiration policy, such as the maximum number of objects in the memory-based cache, which allows the object to be in cache for the longest time, and the maximum idle time allowed for the object to be in the cache. Cached software implementations include the implementation of the cache in hibernate session provided by a third party, hibernate only provides a cache adapter (Cacheprovider). Used to integrate specific cache plugins into hibernate. How caching is enabled as long as the application performs the operations of saving, updating, deleting, loading, and querying database data through the session interface, Hibernate enables the first level cache, copies the data in the database to the cache as objects, and for bulk updates and bulk deletions, If you do not want to enable the first level of caching, you can bypass the Hibernate API and execute the instructions directly through the JDBC API. Users can configure a second-level cache on the granularity of a single collection of classes or classes. If an instance of a class is read frequently but is seldom modified, consider using a second-level cache. Only a second-level cache is configured for a class or collection, and hibernate joins its instance to the second-level cache at run time. How the user manages the cache the first-level cache of physical media is memory, and due to limited memory capacity, the number of loaded objects must be limited by appropriate retrieval policies and retrieval methods. The Evit () method of the session can explicitly empty the cache for specific objects, but this method is not recommended. The second-level cache of physical media can be memory and hard disk, so the secondLevel caches can hold large amounts of data, and the Maxelementsinmemory property value of the data expiration policy can control the number of objects in memory. Managing a second-level cache consists of two main areas: Select the persistence class that needs to use the second level cache, set the appropriate concurrency access policy: Select the cache adapter, and set the appropriate data expiration policy.

Cache Level
When the application invokes the session's Save (), update (), Saveorupdate (), get (), or load (), and the list (), iterate (), or filter () method that invokes the query interface, If the corresponding object does not exist in the session cache, hibernate will add the object to the first level cache. When you clean up the cache, hibernate synchronizes updates to the database based on the state of the objects in the cache. Session provides two ways for the application to manage the cache: evict (object obj): Clears the persisted object specified by the parameter from the cache. Clear (): Empties all persisted objects in the cache.

Second-level cache

The general process for 3.1. Hibernate's level two cache strategy is as follows:

1) When a condition is queried, always issue a SELECT * FROM table_name where .... (select all fields) such SQL statements query the database and get all the data objects at once.

2) Put all the obtained data objects into the second level cache based on the ID.

3) When hibernate accesses the data object according to the ID, it is first checked from the session cache, and if the level two cache is configured, it is checked from the level two cache, and the database is not found, and the result is placed in the cache by ID.

4) Update the cache while deleting, updating, and adding data.

Hibernate's level two cache policy, which is a cache policy for ID queries, has no effect on conditional queries. To do this, Hibernate provides query Cache for conditional queries.

3.2. What kind of data is suitable for storage in the second level cache? 1 rarely modified data 2 is not very important data, allowing the occasional concurrent data 3 will not be accessed concurrently data 4 reference data, refers to the supply of constant data reference, it is limited in number of instances, its instances will be referenced by many other instances of the class, the instance is rarely or never modified

3.3. Not suitable for storing data in a second level cache? 1 frequently modified data 2 financial data, which is absolutely not allowed to occur concurrently with 3 of data shared with other applications.

3.4. Common Cache Plugin Hibernater's level two cache is a plug-in, and here are a few common cache plugins:
l EhCache: As a process-wide cache, the physical media that holds the data can be either memory or hard disk, which provides support for Hibernate's query caching.

l Oscache: As a process-wide cache, the physical media that holds the data can be either memory or hard disk, providing a rich cache data expiration policy that supports Hibernate's query caching.

l Swarmcache: can be used as a cluster-wide cache, but does not support Hibernate's query cache.

l JBossCache: can be used as a cluster-wide cache, supports transactional concurrency access policies, and provides support for hibernate query caching.

By default, Hibernate uses Ehcache for JVM-level caching. Users can specify additional caching policies by setting the properties of the Hibernate.cache.provider_class in the Hibernate configuration file, which must implement Org.hibernate.cache.CacheProvider interface.

3.5. The main steps for configuring level two caching:

1) Select the persistence class that requires a level two cache, and set its concurrent access policy for the named cache. This is the most serious step to consider.

2) Select the appropriate cache plug-in, and then edit the plugin's configuration file.

Lazy Loading
Hibernate Object Relational mappings provide deferred and non-deferred object initialization. Non-lazy loading reads an object in conjunction with all other objects related to the object. This can sometimes result in hundreds of (if not thousands) of SELECT statements being executed when the object is read. This problem sometimes occurs when a bidirectional relationship is used, which often results in the entire database being read at the initialization stage. Of course, you can take the trouble to check each object's relationship with other objects and put those most expensive deletions, but in the end, we might lose the convenience that we wanted to get in the ORM tool.

An obvious workaround is to use the lazy load mechanism provided by Hibernate. This initialization policy reads the relational object only when one of the objects calls it for a pair of many or many-to-many relationships. This process is transparent to the developer, and there are only a few requests for database operations, resulting in significant performance gains. One drawback of this technique is that a lazy-loading technique requires that a hibernate session be kept open while the object is in use. This becomes a major problem when abstracting the persistence layer by using the DAO pattern. In order to completely abstract the persistence mechanism, all database logic, including opening or closing sessions, cannot occur at the application level. Most commonly, some DAO implementation classes that implement simple interfaces encapsulate the database logic completely. A quick but clumsy solution is to discard the DAO pattern and add the database connection logic to the application layer. This may be useful for small applications, but in large systems, this is a serious design flaw that hinders the scalability of the system.

Web-tier lazy loading

Fortunately, the spring framework provides a convenient workaround for hibernate lazy loading and the integration of DAO patterns. As an example of a Web application, Spring provides opensessioninviewfilter and opensessioninviewinterceptor . We are free to choose a class to implement the same functionality. The only difference between the two approaches is that interceptor runs in the spring container and is configured in the context of the Web application, and the filter runs before spring and is configured in XML. Whichever they are, they are requesting the hibernate session to be opened with the current session bound to the current (database) thread. Once bound to a thread, this open hibernate session can be used transparently in the DAO implementation class. This session remains open for a view that delays loading a value object in the database. Once this logical view is complete, the hibernate session is closed in the Dofilter method of the filter or the Posthandle method of the Interceptor. The
implementation method joins

in Web. xml

<filter><filter-name>hibernateFilter</filter-name><filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class></filter><filter-mapping><filter-name>hibernateFilter</filter-name><url-pattern>*.do</url-pattern></filter-mapping>

Performance optimization

Hibernate people may have encountered performance problems, to achieve the same function, hibernate and JDBC performance difference more than 10 times times is normal, if not adjusted early, it is likely to affect the overall progress of the project. Basically, the main considerations for Hibernate performance tuning are as follows:

. Database Design Tuning

. HQL optimization

. Proper use of APIs (e.g., different collections and query APIs based on different business types)

. Main configuration parameters (log, query cache, fetch_size, batch_size, etc.)

. mapping file Optimization (ID generation policy, Level two cache, deferred load, association optimization)

. Management of first-level caches

There are many unique strategies for level two caching.

. transaction control policies.

Database design

A) Reduce the complexity of the association

b) Try not to use the Federated primary key

c) ID generation mechanism, different database provides the mechanism is not exactly the same

d) Appropriate redundant data, not overly pursuing high paradigm

HQL Optimization
HQL If you throw away the association of some caching mechanisms with Hibernate itself, HQL's optimization techniques, like normal SQL optimization techniques, can easily be found on the web.

Master Configuration
A) the query cache, which is not the same as the cache below, is the cache for HQL statements, that is, when the exact same statement executes again, the cached data can be leveraged. However, query caching can be counterproductive in a trading system (where data changes frequently and the odds of querying the same conditions are not large): It can cost a lot of system resources but is difficult to come in handy.

b) Fetch_size, similar to the relevant parameters of JDBC, the parameters are not as large as possible, but should be based on business characteristics to set

c) Batch_size Ibid.

D) in the production system, remember to turn off the SQL statement printing.

Cache
A) database-level caching: This level of caching is most efficient and secure, but different levels of database manageability are not the same, for example, in Oracle, you can specify that the entire table be placed in the cache when you build the table.

b) Session cache: Effective in a hibernatesession, this level of caching is not strong, mostly in hibernate auto-management, but it provides a way to clear the cache, which is effective in large-volume increase/update operations. For example, adding 100,000 records at the same time, in the usual way, is likely to find Outofmemeroy exceptions, and you may need to manually clear this level of cache: Session.evict and Session.clear

c) Application caching: Effective in a sessionfactory, and therefore also the priority of optimization, therefore, a variety of strategies are also considered more, before putting the data into this level of caching, you need to consider some prerequisites:

I. The data will not be modified by a third party (for example, is there another application that is modifying the data?)

II. The data is not too big

III. Data is not updated frequently (otherwise using the cache may backfire)

Iv. data will be frequently queried

V. Data is not a key data (such as money, security, etc.).

There are several forms of caching that can be configured in the mapping file: read-only (read-only, suitable for infrequently changed static data/historical data), Nonstrict-read-write,read-write (more general form, efficiency), transactional (JTA, with fewer supported cache products)

d) Distributed cache: Same as C) configuration, but the choice of cache products, Oscache, JBoss Cache, most of the projects, their use for the cluster (especially the key trading system) conservative attitude. In a clustered environment, using only database-level caches is the safest.

how hibernate works:
1, through the configuration (). Configure (); Read and parse the Hibernate.cfg.xml configuration file.
2, by the Hibernate.cfg.xml in the

Hibernate (Open source Object Relational mapping framework)