Shulou(Shulou.com)06/02 Report--

Editor to share with you what the crawling strategy in Hibernate is like, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Hibernate fetching strategy (fetching strategy) refers to how the Hibernate acquires the associated object policy when the application needs to navigate the associated relationships (of the Hibernate entity object graph).

The fetching strategy can be declared in the metadata of the Oamp R map or overloaded in a specific HQL or conditional query (Criteria Query).

The following Hibernate crawling strategies are available:

◆ connection fetching (Join fetching)-Hibernate obtains the associated instance or collection of objects by using OUTER JOIN (outer join) in the SELECT statement.

◆ query fetching (Select fetching)-sends an additional SELECT statement to grab the associated entity or collection of the current object. Unless you explicitly specify that lazy= "false" forbids deferred fetching (lazy fetching), the second select statement will be executed only when you actually access the relationship.

◆ subquery fetching (Subselect fetching)-sends an additional SELECT statement to grab the associated collection of all entity objects queried (or crawled) earlier. Unless you explicitly specify that lazy= "false" forbids deferred fetching (lazy fetching), the second select statement will be executed only when you actually access the relationship.

◆ batch fetching (Batch fetching)-an optimization for query fetching in which Hibernate uses a single SELECT statement to get a batch of object instances or collections by specifying a list of primary or foreign keys.

The Hibernate fetching strategy distinguishes the following situations:

1.Immediate fetching, fetching immediately-associations, collections, or properties are fetched immediately when the host is loaded.

2.Lazy collection fetching, delay collection fetching-the collection is not fetched until the application performs an operation on the collection. (this is the default behavior for collections. )

3. "Extra-lazy" collection fetching, "Extra-lazy" collection crawl-for each element in the collection class, the database is not accessed until needed. Unless absolutely necessary, Hibernate does not attempt to grab the entire collection into memory (for very large collections).

4.Proxy fetching, proxy fetching-for associations that return a single value, it is grabbed when one of its methods is called rather than get its keyword.

5. "No-proxy" fetching, non-proxy fetching-for associations that return a single value, fetching occurs when the instance variable is accessed. This approach is less "delayed" than the proxy fetching above (even accessing identifiers can lead to association fetching) but is more transparent because the proxy is no longer seen for the application. This method requires bytecode enhancement during compilation, so it is rarely used.

6.Lazy attribute fetching, property delay loading-for a property or association that returns a single value, it is crawled when its instance variable is accessed. Compile-time bytecode enhancement is required, so this approach is rarely necessary.

There are two orthogonal concepts: when the association is fetched, and how it is fetched (what kind of SQL statement will be used). Don't confuse them! We use fetching to improve performance. We use latency to define some contracts and know what data is available for an unmanaged instance of a particular class.

1. The association of operation delay loading

By default, Hibernate 3 uses deferred select fetching for collections and deferred proxy fetching for associations that return a single value. For almost all applications, the vast majority of their associations, this strategy is effective.

Note: if you set hibernate.default_batch_fetch_size,Hibernate, batch crawl optimization will be taken for delayed loading (this optimization may also be turned on at a more refined level).

However, you must understand a problem with delayed fetching. Calling a deferred collection outside of an open Hibernate session context can cause an accident. For example:

S = sessions.openSession (); Transaction tx = s.beginTransaction (); User u = (User) s.createQuery ("from User u where u.name=:userName") .setString ("userName", userName). UniqueResult (); Map permissions = u.getPermissions (); tx.commit (); s.close (); Integer accessLevel = (Integer) permissions.get ("accounts"); / / Error!

After Session is closed, the permessions collection will be uninstantiated and no longer available, so its state cannot be loaded properly. Hibernate does not support delayed instantiation of unmanaged objects. The modification here is to move the code that permissions reads the data to before tx.commit ().

In addition, we can also use non-delayed collections or associations by specifying lazy= "false" to the association mapping. However, for most collections, it is more recommended to crawl data in a deferred manner. If you define too many non-deferred associations in your object model, Hibernate will eventually need to load the entire database into memory in almost every transaction!

However, on the other hand, in some special transactions, we often need to use join fetching (which itself is non-delayed) instead of query fetching. We will soon learn how to customize the fetching strategy in Hibernate. In Hibernate3, the mechanism of choosing which fetching strategy is consistent with the selection of single-valued association or set association.

two。 Adjust grab strategy (Tuning fetch strategies)

Query fetching (default) is extremely fragile in the case of Number1 queries, so we may require that the use of join fetching be defined in the mapping document:

Set

The fetching strategy defined in the mapping document will affect the following list entries: get the data through the get () or load () methods. Data is obtained implicitly only when navigating between associations.

Conditional query, using HQL query crawled by subselect

No matter which fetching strategy you use, class diagrams defined as non-latency are guaranteed to be loaded into memory. Note that this may mean that a HQL query is followed by a series of queries.

In general, we do not use mapping documents to customize fetching strategies. What's more, keep its default value, and then overload it using HQL's left join grab (left join fetch) in a particular transaction. This will tell Hibernate to use external association (outer join) in * queries to get its associated data directly. In the conditional query API, the setFetchMode (FetchMode.JOIN) statement should be called.

Maybe you like to change the data fetching strategy in get () or load () statements simply through conditional queries. For example:

User user = (User) session.createCriteria (User.class) .setFetchMode ("permissions", FetchMode.JOIN) .add (Restrictions.idEq (userId)) .uniqueResult ()

This is the fetch plan equivalent of other ORM solutions in Hibernate. A very different way to avoid Numeric 1 queries is to use a secondary cache.

The above is all the content of this article "what is the crawling strategy in Hibernate?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.