performance.pot

hibernate 开源框架的代码 jar包希望大家能喜欢

msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2007-10-19 10:32-0500\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <[e-mail]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: performance.xml:5(title) 
msgid "Improving performance"
msgstr ""

#: performance.xml:8(title) 
msgid "Fetching strategies"
msgstr ""

#: performance.xml:10(para) 
msgid "A <emphasis>fetching strategy</emphasis> is the strategy Hibernate will use for retrieving associated objects if the application needs to navigate the association. Fetch strategies may be declared in the O/R mapping metadata, or over-ridden by a particular HQL or <literal>Criteria</literal> query."
msgstr ""

#: performance.xml:17(para) 
msgid "Hibernate3 defines the following fetching strategies:"
msgstr ""

#: performance.xml:23(para) 
msgid "<emphasis>Join fetching</emphasis> - Hibernate retrieves the associated instance or collection in the same <literal>SELECT</literal>, using an <literal>OUTER JOIN</literal>."
msgstr ""

#: performance.xml:30(para) 
msgid "<emphasis>Select fetching</emphasis> - a second <literal>SELECT</literal> is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying <literal>lazy=\"false\"</literal>, this second select will only be executed when you actually access the association."
msgstr ""

#: performance.xml:39(para) 
msgid "<emphasis>Subselect fetching</emphasis> - a second <literal>SELECT</literal> is used to retrieve the associated collections for all entities retrieved in a previous query or fetch. Unless you explicitly disable lazy fetching by specifying <literal>lazy=\"false\"</literal>, this second select will only be executed when you actually access the association."
msgstr ""

#: performance.xml:48(para) 
msgid "<emphasis>Batch fetching</emphasis> - an optimization strategy for select fetching - Hibernate retrieves a batch of entity instances or collections in a single <literal>SELECT</literal>, by specifying a list of primary keys or foreign keys."
msgstr ""

#: performance.xml:57(para) 
msgid "Hibernate also distinguishes between:"
msgstr ""

#: performance.xml:63(para) 
msgid "<emphasis>Immediate fetching</emphasis> - an association, collection or attribute is fetched immediately, when the owner is loaded."
msgstr ""

#: performance.xml:69(para) 
msgid "<emphasis>Lazy collection fetching</emphasis> - a collection is fetched when the application invokes an operation upon that collection. (This is the default for collections.)"
msgstr ""

#: performance.xml:76(para) 
msgid "<emphasis>\"Extra-lazy\" collection fetching</emphasis> - individual elements of the collection are accessed from the database as needed. Hibernate tries not to fetch the whole collection into memory unless absolutely needed (suitable for very large collections)"
msgstr ""

#: performance.xml:84(para) 
msgid "<emphasis>Proxy fetching</emphasis> - a single-valued association is fetched when a method other than the identifier getter is invoked upon the associated object."
msgstr ""

#: performance.xml:91(para) 
msgid "<emphasis>\"No-proxy\" fetching</emphasis> - a single-valued association is fetched when the instance variable is accessed. Compared to proxy fetching, this approach is less lazy (the association is fetched even when only the identifier is accessed) but more transparent, since no proxy is visible to the application. This approach requires buildtime bytecode instrumentation and is rarely necessary."
msgstr ""

#: performance.xml:101(para) 
msgid "<emphasis>Lazy attribute fetching</emphasis> - an attribute or single valued association is fetched when the instance variable is accessed. This approach requires buildtime bytecode instrumentation and is rarely necessary."
msgstr ""

#: performance.xml:110(para) 
msgid "We have two orthogonal notions here: <emphasis>when</emphasis> is the association fetched, and <emphasis>how</emphasis> is it fetched (what SQL is used). Don't confuse them! We use <literal>fetch</literal> to tune performance. We may use <literal>lazy</literal> to define a contract for what data is always available in any detached instance of a particular class."
msgstr ""

#: performance.xml:119(title) 
msgid "Working with lazy associations"
msgstr ""

#: performance.xml:121(para) 
msgid "By default, Hibernate3 uses lazy select fetching for collections and lazy proxy fetching for single-valued associations. These defaults make sense for almost all associations in almost all applications."
msgstr ""

#: performance.xml:127(para) 
msgid "<emphasis>Note:</emphasis> if you set <literal>hibernate.default_batch_fetch_size</literal>, Hibernate will use the batch fetch optimization for lazy fetching (this optimization may also be enabled at a more granular level)."
msgstr ""

#: performance.xml:134(para) 
msgid "However, lazy fetching poses one problem that you must be aware of. Access to a lazy association outside of the context of an open Hibernate session will result in an exception. For example:"
msgstr ""

#: performance.xml:152(para) 
msgid "Since the permissions collection was not initialized when the <literal>Session</literal> was closed, the collection will not be able to load its state. <emphasis>Hibernate does not support lazy initialization for detached objects</emphasis>. The fix is to move the code that reads from the collection to just before the transaction is committed."
msgstr ""

#: performance.xml:160(para) 
msgid "Alternatively, we could use a non-lazy collection or association, by specifying <literal>lazy=\"false\"</literal> for the association mapping. However, it is intended that lazy initialization be used for almost all collections and associations. If you define too many non-lazy associations in your object model, Hibernate will end up needing to fetch the entire database into memory in every transaction!"
msgstr ""

#: performance.xml:169(para) 
msgid "On the other hand, we often want to choose join fetching (which is non-lazy by nature) instead of select fetching in a particular transaction. We'll now see how to customize the fetching strategy. In Hibernate3, the mechanisms for choosing a fetch strategy are identical for single-valued associations and collections."
msgstr ""

#: performance.xml:180(title) 
msgid "Tuning fetch strategies"
msgstr ""

#: performance.xml:182(para) 
msgid "Select fetching (the default) is extremely vulnerable to N+1 selects problems, so we might want to enable join fetching in the mapping document:"
msgstr ""

#: performance.xml:195(para) 
msgid "The <literal>fetch</literal> strategy defined in the mapping document affects:"
msgstr ""

#: performance.xml:201(para) 
msgid "retrieval via <literal>get()</literal> or <literal>load()</literal>"
msgstr ""

#: performance.xml:206(para) 
msgid "retrieval that happens implicitly when an association is navigated"
msgstr ""

#: performance.xml:211(para) 
msgid "<literal>Criteria</literal> queries"
msgstr ""

#: performance.xml:216(para) 
msgid "HQL queries if <literal>subselect</literal> fetching is used"
msgstr ""

#: performance.xml:222(para) 
msgid "No matter what fetching strategy you use, the defined non-lazy graph is guaranteed to be loaded into memory. Note that this might result in several immediate selects being used to execute a particular HQL query."
msgstr ""

#: performance.xml:228(para) 
msgid "Usually, we don't use the mapping document to customize fetching. Instead, we keep the default behavior, and override it for a particular transaction, using <literal>left join fetch</literal> in HQL. This tells Hibernate to fetch the association eagerly in the first select, using an outer join. In the <literal>Criteria</literal> query API, you would use <literal>setFetchMode(FetchMode.JOIN)</literal>."
msgstr ""

#: performance.xml:237(para) 
msgid "If you ever feel like you wish you could change the fetching strategy used by <literal>get()</literal> or <literal>load()</literal>, simply use a <literal>Criteria</literal> query, for example:"
msgstr ""

#: performance.xml:248(para) 
msgid "(This is Hibernate's equivalent of what some ORM solutions call a \"fetch plan\".)"
msgstr ""

#: performance.xml:252(para) 
msgid "A completely different way to avoid problems with N+1 selects is to use the second-level cache."
msgstr ""

#: performance.xml:260(title) 
msgid "Single-ended association proxies"
msgstr ""

#: performance.xml:262(para) 
msgid "Lazy fetching for collections is implemented using Hibernate's own implementation of persistent collections. However, a different mechanism is needed for lazy behavior in single-ended associations. The target entity of the association must be proxied. Hibernate implements lazy initializing proxies for persistent objects using runtime bytecode enhancement (via the excellent CGLIB library)."
msgstr ""

#: performance.xml:270(para) 
msgid "By default, Hibernate3 generates proxies (at startup) for all persistent classes and uses them to enable lazy fetching of <literal>many-to-one</literal> and <literal>one-to-one</literal> associations."
msgstr ""

#: performance.xml:276(para) 
msgid "The mapping file may declare an interface to use as the proxy interface for that class, with the <literal>proxy</literal> attribute. By default, Hibernate uses a subclass of the class. <emphasis>Note that the proxied class must implement a default constructor with at least package visibility. We recommend this constructor for all persistent classes!</emphasis>"
msgstr ""

#: performance.xml:283(para) 
msgid "There are some gotchas to be aware of when extending this approach to polymorphic classes, eg."
msgstr ""

#: performance.xml:295(para) 
msgid "Firstly, instances of <literal>Cat</literal> will never be castable to <literal>DomesticCat</literal>, even if the underlying instance is an instance of <literal>DomesticCat</literal>:"
msgstr ""

#: performance.xml:307(para) 
msgid "Secondly, it is possible to break proxy <literal>==</literal>."
msgstr ""

#: performance.xml:316(para) 
msgid "However, the situation is not quite as bad as it looks. Even though we now have two references to different proxy objects, the underlying instance will still be the same object:"
msgstr ""

#: performance.xml:324(para) 
msgid "Third, you may not use a CGLIB proxy for a <literal>final</literal> class or a class with any <literal>final</literal> methods."
msgstr ""

#: performance.xml:329(para) 
msgid "Finally, if your persistent object acquires any resources upon instantiation (eg. in initializers or default constructor), then those resources will also be acquired by the proxy. The proxy class is an actual subclass of the persistent class."
msgstr ""

#: performance.xml:335(para) 
msgid "These problems are all due to fundamental limitations in Java's single inheritance model. If you wish to avoid these problems your persistent classes must each implement an interface that declares its business methods. You should specify these interfaces in the mapping file. eg."
msgstr ""

#: performance.xml:348(para) 
msgid "where <literal>CatImpl</literal> implements the interface <literal>Cat</literal> and <literal>DomesticCatImpl</literal> implements the interface <literal>DomesticCat</literal>. Then proxies for instances of <literal>Cat</literal> and <literal>DomesticCat</literal> may be returned by <literal>load()</literal> or <literal>iterate()</literal>. (Note that <literal>list()</literal> does not usually return proxies.)"
msgstr ""

#: performance.xml:360(para) 
msgid "Relationships are also lazily initialized. This means you must declare any properties to be of type <literal>Cat</literal>, not <literal>CatImpl</literal>."
msgstr ""