Hibernate crawl Strategy Fetch/batch-size

Instance a refers to an instance b,b if it is an agent (for example, in a Many-to-many Association): If you traverse A's query result set (assuming there are 10 records), accessing the B variable while traversing a, will result in N-time query statements being sent. At this point, if you configure batch-size,hibernate on the class at the end of B, you will reduce the number of SQL statements.

Hibernate can be fully effective in using bulk crawls, that is, if only one access agent (or collection), then hibernate will not load other instantiations agents. Batch fetching is an optimization scheme for delayed query grabbing, and you can choose between two batch fetching schemes: At the class level and at the collection level.

Bulk crawl at class/entity level is easy to understand, assuming that you will need to face the following problem at run time: you loaded 25 cat instances in a session, each cat instance has a reference member owner, which points to persion, and the Persion class is a proxy, At the same time lazy=true, if you have to traverse the refurbishment cats collection and Invoke the GetOwner () method for each element, hibernate will execute the 25 select query by default and get its Ower proxy object. At this point you can change the behavior by explicitly declaring batch-size in the person attribute of the mapping file:

<class name= "Person" batch-size= "ten" >...</class>, Hibernate will only need to execute three queries, respectively, 10,10,5.

A crawl strategy (fetching strategy) is when an application needs to navigate between associated relationships (Hibernate the Entity object graph) Hibernate how to get the policy for the associated object. A crawl policy can be declared in the metadata of the O/R map, or it can be overloaded in a particular HQL or criteria query.

The

hibernate3  defines the following crawl strategies: connection fetching (join fetching)  -Hibernate obtains an associated instance of an object or a collection of associations by using a OUTER join (outer join) in a SELECT statement. Query grabbing (select fetching)  -sends a SELECT statement to crawl the associated entity or collection of the current object. Unless you explicitly specify lazy= "false" to prohibit deferred fetching (lazy fetching), the second SELECT statement is executed only when you truly access the association relationship. Subquery Crawl (subselect fetching)  -sends another SELECT statement to crawl the collection of associations for all entity objects that were previously queried (or crawled). Unless you explicitly specify lazy= "false" to prohibit deferred fetching (lazy fetching), the second SELECT statement is executed only when you truly access the association relationship. Batch crawl (Batch fetching)  -optimization scheme for query fetching by specifying a primary key or foreign key list, Hibernate uses a single SELECT statement to get a batch of object instances or collections.

Hibernate distinguishes between the following situations: Immediate fetching, immediate crawl-when the host is loaded, the association, collection, or property is immediately crawled. Lazy collection fetching, deferred collection grabbing-the collection is crawled until an application has an operation on the collection. (This is the default behavior for collections.) "Extra-lazy" collection fetching, "Extra-lazy" collection capture-for each element in the collection class, the database is accessed until it is needed. Unless absolutely necessary, Hibernate does not attempt to crawl the entire collection into memory (for very large collections). Proxy fetching, agent crawl-for an association that returns a single value, it is crawled when a method is invoked rather than a get operation on its keyword. "No-proxy" fetching, non-proxy crawl-for associations that return a single value, crawl when an instance variable is accessed. This approach is less "delayed" than the above agent crawl (even if the identifier is only accessed, it can also cause affinity crawling) but is more transparent because the application is no longer seeing a proxy. This approach requires bytecode enhancement operations during compilation, so it is rarely needed. Lazy attribute fetching, property deferred loading-for the association of a property or return single value, crawl when its instance variable is accessed. Compile-time bytecode hardening is required, so this approach is rarely necessary.

Here are two orthogonal concepts: when the association is crawled and how it is crawled (what SQL statement is used). Don't confuse them. We use crawling to improve performance. We use latency to define contracts, and to know what data is available to an instance of a particular class's removal.

  Java code: View Copy to clipboard print Hibernate crawl strategy (bulk crawl for single-end agents)              Keep default, With fetch= "Select", such as:      <many-to-one name= "Classes"  column= "Classesid"   Fetch= "Select"/>             fetch= "select", Send a SELECT statement to crawl the current object association entity or collection              set fetch= "join", such as:      <many-to-one name= "Classes"  column= "Classesid"  fetch= "join"/>             fetch= "Join", Hibernate uses an outer join to load its associated entity or collection      through a SELECT statement          This time lazy will fail                      Hibernate crawl strategy (bulk crawl of collection agents)              Keep the default, Same Fetch= "Select", such as:      <set name= "Students"  inverse= "true"  cascade= "all"  fetch= "Select" >             fetch= "select" and send a SELECT statement to crawl the current object association entity or collection              Hibernate crawl strategy (bulk crawl of collection agents)               set fetch= "join", such as:      <set name= "Students"  inverse= " True '  cascade= ' all '  fetch= ' join ' >             fetch= ' Join, Hibernate uses an outer join to load its associated entities or collections through a SELECT statement