transactions.pot

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

#: transactions.xml:775(para) 
msgid "A single <literal>Session</literal> instance and its persistent instances are used for the whole conversation, known as <emphasis>session-per-conversation</emphasis>. Hibernate checks instance versions at flush time, throwing an exception if concurrent modification is detected. It's up to the developer to catch and handle this exception (common options are the opportunity for the user to merge changes or to restart the business conversation with non-stale data)."
msgstr ""

#: transactions.xml:784(para) 
msgid "The <literal>Session</literal> is disconnected from any underlying JDBC connection when waiting for user interaction. This approach is the most efficient in terms of database access. The application need not concern itself with version checking or with reattaching detached instances, nor does it have to reload instances in every database transaction."
msgstr ""

#: transactions.xml:800(para) 
msgid "The <literal>foo</literal> object still knows which <literal>Session</literal> it was loaded in. Beginning a new database transaction on an old session obtains a new connection and resumes the session. Committing a database transaction disconnects a session from the JDBC connection and returns the connection to the pool. After reconnection, to force a version check on data you aren't updating, you may call <literal>Session.lock()</literal> with <literal>LockMode.READ</literal> on any objects that might have been updated by another transaction. You don't need to lock any data that you <emphasis>are</emphasis> updating. Usually you would set <literal>FlushMode.MANUAL</literal> on an extended <literal>Session</literal>, so that only the last database transaction cycle is allowed to actually persist all modifications made in this conversation. Hence, only this last database transaction would include the <literal>flush()</literal> operation, and then also <literal>close()</literal> the session to end the conversation."
msgstr ""

#: transactions.xml:815(para) 
msgid "This pattern is problematic if the <literal>Session</literal> is too big to be stored during user think time, e.g. an <literal>HttpSession</literal> should be kept as small as possible. As the <literal>Session</literal> is also the (mandatory) first-level cache and contains all loaded objects, we can probably use this strategy only for a few request/response cycles. You should use a <literal>Session</literal> only for a single conversation, as it will soon also have stale data."
msgstr ""

#: transactions.xml:825(para) 
msgid "(Note that earlier Hibernate versions required explicit disconnection and reconnection of a <literal>Session</literal>. These methods are deprecated, as beginning and ending a transaction has the same effect.)"
msgstr ""

#: transactions.xml:831(para) 
msgid "Also note that you should keep the disconnected <literal>Session</literal> close to the persistence layer. In other words, use an EJB stateful session bean to hold the <literal>Session</literal> in a three-tier environment, and don't transfer it to the web layer (or even serialize it to a separate tier) to store it in the <literal>HttpSession</literal>."
msgstr ""

#: transactions.xml:839(para) 
msgid "The extended session pattern, or <emphasis>session-per-conversation</emphasis>, is more difficult to implement with automatic current session context management. You need to supply your own implementation of the <literal>CurrentSessionContext</literal> for this, see the Hibernate Wiki for examples."
msgstr ""

#: transactions.xml:849(title) 
msgid "Detached objects and automatic versioning"
msgstr ""

#: transactions.xml:851(para) 
msgid "Each interaction with the persistent store occurs in a new <literal>Session</literal>. However, the same persistent instances are reused for each interaction with the database. The application manipulates the state of detached instances originally loaded in another <literal>Session</literal> and then reattaches them using <literal>Session.update()</literal>, <literal>Session.saveOrUpdate()</literal>, or <literal>Session.merge()</literal>."
msgstr ""

#: transactions.xml:867(para) 
msgid "Again, Hibernate will check instance versions during flush, throwing an exception if conflicting updates occured."
msgstr ""

#: transactions.xml:872(para) 
msgid "You may also call <literal>lock()</literal> instead of <literal>update()</literal> and use <literal>LockMode.READ</literal> (performing a version check, bypassing all caches) if you are sure that the object has not been modified."
msgstr ""

#: transactions.xml:881(title) 
msgid "Customizing automatic versioning"
msgstr ""

#: transactions.xml:883(para) 
msgid "You may disable Hibernate's automatic version increment for particular properties and collections by setting the <literal>optimistic-lock</literal> mapping attribute to <literal>false</literal>. Hibernate will then no longer increment versions if the property is dirty."
msgstr ""

#: transactions.xml:890(para) 
msgid "Legacy database schemas are often static and can't be modified. Or, other applications might also access the same database and don't know how to handle version numbers or even timestamps. In both cases, versioning can't rely on a particular column in a table. To force a version check without a version or timestamp property mapping, with a comparison of the state of all fields in a row, turn on <literal>optimistic-lock=\"all\"</literal> in the <literal>&lt;class&gt;</literal> mapping. Note that this concepetually only works if Hibernate can compare the old and new state, i.e. if you use a single long <literal>Session</literal> and not session-per-request-with-detached-objects."
msgstr ""

#: transactions.xml:901(para) 
msgid "Sometimes concurrent modification can be permitted as long as the changes that have been made don't overlap. If you set <literal>optimistic-lock=\"dirty\"</literal> when mapping the <literal>&lt;class&gt;</literal>, Hibernate will only compare dirty fields during flush."
msgstr ""

#: transactions.xml:907(para) 
msgid "In both cases, with dedicated version/timestamp columns or with full/dirty field comparison, Hibernate uses a single <literal>UPDATE</literal> statement (with an appropriate <literal>WHERE</literal> clause) per entity to execute the version check and update the information. If you use transitive persistence to cascade reattachment to associated entities, Hibernate might execute uneccessary updates. This is usually not a problem, but <emphasis>on update</emphasis> triggers in the database might be executed even when no changes have been made to detached instances. You can customize this behavior by setting <literal>select-before-update=\"true\"</literal> in the <literal>&lt;class&gt;</literal> mapping, forcing Hibernate to <literal>SELECT</literal> the instance to ensure that changes did actually occur, before updating the row."
msgstr ""

#: transactions.xml:925(title) 
msgid "Pessimistic Locking"
msgstr ""

#: transactions.xml:927(para) 
msgid "It is not intended that users spend much time worring about locking strategies. Its usually enough to specify an isolation level for the JDBC connections and then simply let the database do all the work. However, advanced users may sometimes wish to obtain exclusive pessimistic locks, or re-obtain locks at the start of a new transaction."
msgstr ""

#: transactions.xml:934(para) 
msgid "Hibernate will always use the locking mechanism of the database, never lock objects in memory!"
msgstr ""

#: transactions.xml:939(para) 
msgid "The <literal>LockMode</literal> class defines the different lock levels that may be acquired by Hibernate. A lock is obtained by the following mechanisms:"
msgstr ""

#: transactions.xml:946(para) 
msgid "<literal>LockMode.WRITE</literal> is acquired automatically when Hibernate updates or inserts a row."
msgstr ""

#: transactions.xml:952(para) 
msgid "<literal>LockMode.UPGRADE</literal> may be acquired upon explicit user request using <literal>SELECT ... FOR UPDATE</literal> on databases which support that syntax."
msgstr ""

#: transactions.xml:958(para) 
msgid "<literal>LockMode.UPGRADE_NOWAIT</literal> may be acquired upon explicit user request using a <literal>SELECT ... FOR UPDATE NOWAIT</literal> under Oracle."
msgstr ""

#: transactions.xml:964(para) 
msgid "<literal>LockMode.READ</literal> is acquired automatically when Hibernate reads data under Repeatable Read or Serializable isolation level. May be re-acquired by explicit user request."
msgstr ""

#: transactions.xml:971(para) 
msgid "<literal>LockMode.NONE</literal> represents the absence of a lock. All objects switch to this lock mode at the end of a <literal>Transaction</literal>. Objects associated with the session via a call to <literal>update()</literal> or <literal>saveOrUpdate()</literal> also start out in this lock mode."
msgstr ""

#: transactions.xml:980(para) 
msgid "The \"explicit user request\" is expressed in one of the following ways:"
msgstr ""

#: transactions.xml:986(para) 
msgid "A call to <literal>Session.load()</literal>, specifying a <literal>LockMode</literal>."
msgstr ""

#: transactions.xml:991(para) 
msgid "A call to <literal>Session.lock()</literal>."
msgstr ""

#: transactions.xml:996(para) 
msgid "A call to <literal>Query.setLockMode()</literal>."
msgstr ""

#: transactions.xml:1002(para) 
msgid "If <literal>Session.load()</literal> is called with <literal>UPGRADE</literal> or <literal>UPGRADE_NOWAIT</literal>, and the requested object was not yet loaded by the session, the object is loaded using <literal>SELECT ... FOR UPDATE</literal>. If <literal>load()</literal> is called for an object that is already loaded with a less restrictive lock than the one requested, Hibernate calls <literal>lock()</literal> for that object."
msgstr ""

#: transactions.xml:1011(para) 
msgid "<literal>Session.lock()</literal> performs a version number check if the specified lock mode is <literal>READ</literal>, <literal>UPGRADE</literal> or <literal>UPGRADE_NOWAIT</literal>. (In the case of <literal>UPGRADE</literal> or <literal>UPGRADE_NOWAIT</literal>, <literal>SELECT ... FOR UPDATE</literal> is used.)"
msgstr ""

#: transactions.xml:1018(para) 
msgid "If the database does not support the requested lock mode, Hibernate will use an appropriate alternate mode (instead of throwing an exception). This ensures that applications will be portable."
msgstr ""

#: transactions.xml:1027(title) 
msgid "Connection Release Modes"
msgstr ""

#: transactions.xml:1029(para) 
msgid "The legacy (2.x) behavior of Hibernate in regards to JDBC connection management was that a <literal>Session</literal> would obtain a connection when it was first needed and then hold unto that connection until the session was closed. Hibernate 3.x introduced the notion of connection release modes to tell a session how to handle its JDBC connections. Note that the following discussion is pertinent only to connections provided through a configured <literal>ConnectionProvider</literal>; user-supplied connections are outside the breadth of this discussion. The different release modes are identified by the enumerated values of <literal>org.hibernate.ConnectionReleaseMode</literal>:"
msgstr ""

#: transactions.xml:1043(para) 
msgid "<literal>ON_CLOSE</literal> - is essentially the legacy behavior described above. The Hibernate session obatins a connection when it first needs to perform some JDBC access and holds unto that connection until the session is closed."
msgstr ""

#: transactions.xml:1050(para) 
msgid "<literal>AFTER_TRANSACTION</literal> - says to release connections after a <literal>org.hibernate.Transaction</literal> has completed."
msgstr ""

#: transactions.xml:1056(para) 
msgid "<literal>AFTER_STATEMENT</literal> (also referred to as aggressive release) - says to release connections after each and every statement execution. This aggressive releasing is skipped if that statement leaves open resources associated with the given session; currently the only situation where this occurs is through the use of <literal>org.hibernate.ScrollableResults</literal>."
msgstr ""

#: transactions.xml:1066(para) 
msgid "The configuration parameter <literal>hibernate.connection.release_mode</literal> is used to specify which release mode to use. The possible values:"
msgstr ""

#: transactions.xml:1073(para) 
msgid "<literal>auto</literal> (the default) - this choice delegates to the release mode returned by the <literal>org.hibernate.transaction.TransactionFactory.getDefaultReleaseMode()</literal> method. For JTATransactionFactory, this returns ConnectionReleaseMode.AFTER_STATEMENT; for JDBCTransactionFactory, this returns ConnectionReleaseMode.AFTER_TRANSACTION. It is rarely a good idea to change this default behavior as failures due to the value of this setting tend to indicate bugs and/or invalid assumptions in user code."
msgstr ""

#: transactions.xml:1083(para) 
msgid "<literal>on_close</literal> - says to use ConnectionReleaseMode.ON_CLOSE. This setting is left for backwards compatibility, but its use is highly discouraged."
msgstr ""

#: transactions.xml:1089(para) 
msgid "<literal>after_transaction</literal> - says to use ConnectionReleaseMode.AFTER_TRANSACTION. This setting should not be used in JTA environments. Also note that with ConnectionReleaseMode.AFTER_TRANSACTION, if a session is considered to be in auto-commit mode connections will be released as if the release mode were AFTER_STATEMENT."
msgstr ""

#: transactions.xml:1097(para) 
msgid "<literal>after_statement</literal> - says to use ConnectionReleaseMode.AFTER_STATEMENT. Additionally, the configured <literal>ConnectionProvider</literal> is consulted to see if it supports this setting (<literal>supportsAggressiveRelease()</literal>). If not, the release mode is reset to ConnectionReleaseMode.AFTER_TRANSACTION. This setting is only safe in environments where we can either re-acquire the same underlying JDBC connection each time we make a call into <literal>ConnectionProvider.getConnection()</literal> or in auto-commit environments where it does not matter whether we get back the same connection."
msgstr ""

#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2.
#: transactions.xml:0(None) 
msgid "translator-credits"
msgstr ""