performance.pot

来自「hibernate 开源框架的代码 jar包希望大家能喜欢」· POT 代码 · 共 809 行 · 第 1/4 页

#: performance.xml:691(entry) performance.xml:878(entry) 
msgid "SwarmCache"
msgstr ""

#: performance.xml:692(literal) 
msgid "org.hibernate.cache.SwarmCacheProvider"
msgstr ""

#: performance.xml:693(entry) 
msgid "clustered (ip multicast)"
msgstr ""

#: performance.xml:694(entry) 
msgid "yes (clustered invalidation)"
msgstr ""

#: performance.xml:698(entry) performance.xml:885(entry) 
msgid "JBoss TreeCache"
msgstr ""

#: performance.xml:699(literal) 
msgid "org.hibernate.cache.TreeCacheProvider"
msgstr ""

#: performance.xml:700(entry) 
msgid "clustered (ip multicast), transactional"
msgstr ""

#: performance.xml:701(entry) 
msgid "yes (replication)"
msgstr ""

#: performance.xml:702(entry) 
msgid "yes (clock sync req.)"
msgstr ""

#: performance.xml:709(title) 
msgid "Cache mappings"
msgstr ""

#: performance.xml:711(para) 
msgid "The <literal>&lt;cache&gt;</literal> element of a class or collection mapping has the following form:"
msgstr ""

#: performance.xml:729(para) 
msgid "<literal>usage</literal> (required) specifies the caching strategy: <literal>transactional</literal>, <literal>read-write</literal>, <literal>nonstrict-read-write</literal> or <literal>read-only</literal>"
msgstr ""

#: performance.xml:738(para) 
msgid "<literal>region</literal> (optional, defaults to the class or collection role name) specifies the name of the second level cache region"
msgstr ""

#: performance.xml:745(para) 
msgid "<literal>include</literal> (optional, defaults to <literal>all</literal>) <literal>non-lazy</literal> specifies that properties of the entity mapped with <literal>lazy=\"true\"</literal> may not be cached when attribute-level lazy fetching is enabled"
msgstr ""

#: performance.xml:755(para) 
msgid "Alternatively (preferrably?), you may specify <literal>&lt;class-cache&gt;</literal> and <literal>&lt;collection-cache&gt;</literal> elements in <literal>hibernate.cfg.xml</literal>."
msgstr ""

#: performance.xml:760(para) 
msgid "The <literal>usage</literal> attribute specifies a <emphasis>cache concurrency strategy</emphasis>."
msgstr ""

#: performance.xml:767(title) 
msgid "Strategy: read only"
msgstr ""

#: performance.xml:769(para) 
msgid "If your application needs to read but never modify instances of a persistent class, a <literal>read-only</literal> cache may be used. This is the simplest and best performing strategy. It's even perfectly safe for use in a cluster."
msgstr ""

#: performance.xml:784(title) 
msgid "Strategy: read/write"
msgstr ""

#: performance.xml:786(para) 
msgid "If the application needs to update data, a <literal>read-write</literal> cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property <literal>hibernate.transaction.manager_lookup_class</literal>, naming a strategy for obtaining the JTA <literal>TransactionManager</literal>. In other environments, you should ensure that the transaction is completed when <literal>Session.close()</literal> or <literal>Session.disconnect()</literal> is called. If you wish to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do <emphasis>not</emphasis>."
msgstr ""

#: performance.xml:809(title) 
msgid "Strategy: nonstrict read/write"
msgstr ""

#: performance.xml:811(para) 
msgid "If the application only occasionally needs to update data (ie. if it is extremely unlikely that two transactions would try to update the same item simultaneously) and strict transaction isolation is not required, a <literal>nonstrict-read-write</literal> cache might be appropriate. If the cache is used in a JTA environment, you must specify <literal>hibernate.transaction.manager_lookup_class</literal>. In other environments, you should ensure that the transaction is completed when <literal>Session.close()</literal> or <literal>Session.disconnect()</literal> is called."
msgstr ""

#: performance.xml:823(title) 
msgid "Strategy: transactional"
msgstr ""

#: performance.xml:825(para) 
msgid "The <literal>transactional</literal> cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache may only be used in a JTA environment and you must specify <literal>hibernate.transaction.manager_lookup_class</literal>."
msgstr ""

#: performance.xml:833(para) 
msgid "None of the cache providers support all of the cache concurrency strategies. The following table shows which providers are compatible with which concurrency strategies."
msgstr ""

#: performance.xml:839(title) 
msgid "Cache Concurrency Strategy Support"
msgstr ""

#: performance.xml:849(entry) 
msgid "read-only"
msgstr ""

#: performance.xml:850(entry) 
msgid "nonstrict-read-write"
msgstr ""

#: performance.xml:851(entry) 
msgid "read-write"
msgstr ""

#: performance.xml:852(entry) 
msgid "transactional"
msgstr ""

#: performance.xml:898(title) 
msgid "Managing the caches"
msgstr ""

#: performance.xml:900(para) 
msgid "Whenever you pass an object to <literal>save()</literal>, <literal>update()</literal> or <literal>saveOrUpdate()</literal> and whenever you retrieve an object using <literal>load()</literal>, <literal>get()</literal>, <literal>list()</literal>, <literal>iterate()</literal> or <literal>scroll()</literal>, that object is added to the internal cache of the <literal>Session</literal>."
msgstr ""

#: performance.xml:907(para) 
msgid "When <literal>flush()</literal> is subsequently called, the state of that object will be synchronized with the database. If you do not want this synchronization to occur or if you are processing a huge number of objects and need to manage memory efficiently, the <literal>evict()</literal> method may be used to remove the object and its collections from the first-level cache."
msgstr ""

#: performance.xml:922(para) 
msgid "The <literal>Session</literal> also provides a <literal>contains()</literal> method to determine if an instance belongs to the session cache."
msgstr ""

#: performance.xml:927(para) 
msgid "To completely evict all objects from the session cache, call <literal>Session.clear()</literal>"
msgstr ""

#: performance.xml:931(para) 
msgid "For the second-level cache, there are methods defined on <literal>SessionFactory</literal> for evicting the cached state of an instance, entire class, collection instance or entire collection role."
msgstr ""

#: performance.xml:942(para) 
msgid "The <literal>CacheMode</literal> controls how a particular session interacts with the second-level cache."
msgstr ""

#: performance.xml:949(para) 
msgid "<literal>CacheMode.NORMAL</literal> - read items from and write items to the second-level cache"
msgstr ""

#: performance.xml:954(para) 
msgid "<literal>CacheMode.GET</literal> - read items from the second-level cache, but don't write to the second-level cache except when updating data"
msgstr ""

#: performance.xml:960(para) 
msgid "<literal>CacheMode.PUT</literal> - write items to the second-level cache, but don't read from the second-level cache"
msgstr ""

#: performance.xml:966(para) 
msgid "<literal>CacheMode.REFRESH</literal> - write items to the second-level cache, but don't read from the second-level cache, bypass the effect of <literal>hibernate.cache.use_minimal_puts</literal>, forcing a refresh of the second-level cache for all items read from the database"
msgstr ""

#: performance.xml:974(para) 
msgid "To browse the contents of a second-level or query cache region, use the <literal>Statistics</literal> API:"
msgstr ""

#: performance.xml:983(para) 
msgid "You'll need to enable statistics, and, optionally, force Hibernate to keep the cache entries in a more human-understandable format:"
msgstr ""

#: performance.xml:994(title) 
msgid "The Query Cache"
msgstr ""

#: performance.xml:996(para) 
msgid "Query result sets may also be cached. This is only useful for queries that are run frequently with the same parameters. To use the query cache you must first enable it:"
msgstr ""

#: performance.xml:1003(para) 
msgid "This setting causes the creation of two new cache regions - one holding cached query result sets (<literal>org.hibernate.cache.StandardQueryCache</literal>), the other holding timestamps of the most recent updates to queryable tables (<literal>org.hibernate.cache.UpdateTimestampsCache</literal>). Note that the query cache does not cache the state of the actual entities in the result set; it caches only identifier values and results of value type. So the query cache should always be used in conjunction with the second-level cache."
msgstr ""

#: performance.xml:1013(para) 
msgid "Most queries do not benefit from caching, so by default queries are not cached. To enable caching, call <literal>Query.setCacheable(true)</literal>. This call allows the query to look for existing cache results or add its results to the cache when it is executed."
msgstr ""

#: performance.xml:1020(para) 
msgid "If you require fine-grained control over query cache expiration policies, you may specify a named cache region for a particular query by calling <literal>Query.setCacheRegion()</literal>."
msgstr ""

#: performance.xml:1033(para) 
msgid "If the query should force a refresh of its query cache region, you should call <literal>Query.setCacheMode(CacheMode.REFRESH)</literal>. This is particularly useful in cases where underlying data may have been updated via a separate process (i.e., not modified through Hibernate) and allows the application to selectively refresh particular query result sets. This is a more efficient alternative to eviction of a query cache region via <literal>SessionFactory.evictQueries()</literal>."
msgstr ""

#: performance.xml:1045(title) 
msgid "Understanding Collection performance"
msgstr ""

#: performance.xml:1047(para) 
msgid "We've already spent quite some time talking about collections. In this section we will highlight a couple more issues about how collections behave at runtime."