transactions.pot

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

#: transactions.xml:348(title) 
msgid "Database transaction demarcation"
msgstr ""

#: transactions.xml:350(para) 
msgid "Datatabase (or system) transaction boundaries are always necessary. No communication with the database can occur outside of a database transaction (this seems to confuse many developers who are used to the auto-commit mode). Always use clear transaction boundaries, even for read-only operations. Depending on your isolation level and database capabilities this might not be required but there is no downside if you always demarcate transactions explicitly. Certainly, a single database transaction is going to perform better than many small transactions, even for reading data."
msgstr ""

#: transactions.xml:360(para) 
msgid "A Hibernate application can run in non-managed (i.e. standalone, simple Web- or Swing applications) and managed J2EE environments. In a non-managed environment, Hibernate is usually responsible for its own database connection pool. The application developer has to manually set transaction boundaries, in other words, begin, commit, or rollback database transactions himself. A managed environment usually provides container-managed transactions (CMT), with the transaction assembly defined declaratively in deployment descriptors of EJB session beans, for example. Programmatic transaction demarcation is then no longer necessary."
msgstr ""

#: transactions.xml:370(para) 
msgid "However, it is often desirable to keep your persistence layer portable between non-managed resource-local environments, and systems that can rely on JTA but use BMT instead of CMT. In both cases you'd use programmatic transaction demaracation. Hibernate offers a wrapper API called <literal>Transaction</literal> that translates into the native transaction system of your deployment environment. This API is actually optional, but we strongly encourage its use unless you are in a CMT session bean."
msgstr ""

#: transactions.xml:379(para) 
msgid "Usually, ending a <literal>Session</literal> involves four distinct phases:"
msgstr ""

#: transactions.xml:385(para) 
msgid "flush the session"
msgstr ""

#: transactions.xml:390(para) 
msgid "commit the transaction"
msgstr ""

#: transactions.xml:395(para) 
msgid "close the session"
msgstr ""

#: transactions.xml:400(para) 
msgid "handle exceptions"
msgstr ""

#: transactions.xml:406(para) 
msgid "Flushing the session has been discussed earlier, we'll now have a closer look at transaction demarcation and exception handling in both managed- and non-managed environments."
msgstr ""

#: transactions.xml:413(title) 
msgid "Non-managed environment"
msgstr ""

#: transactions.xml:415(para) 
msgid "If a Hibernate persistence layer runs in a non-managed environment, database connections are usually handled by simple (i.e. non-DataSource) connection pools from which Hibernate obtains connections as needed. The session/transaction handling idiom looks like this:"
msgstr ""

#: transactions.xml:441(para) 
msgid "You don't have to <literal>flush()</literal> the <literal>Session</literal> explicitly - the call to <literal>commit()</literal> automatically triggers the synchronization (depending upon the <xref linkend=\"objectstate-flushing\">FlushMode</xref> for the session. A call to <literal>close()</literal> marks the end of a session. The main implication of <literal>close()</literal> is that the JDBC connection will be relinquished by the session. This Java code is portable and runs in both non-managed and JTA environments."
msgstr ""

#: transactions.xml:450(para) 
msgid "A much more flexible solution is Hibernate's built-in \"current session\" context management, as described earlier:"
msgstr ""

#: transactions.xml:469(para) 
msgid "You will very likely never see these code snippets in a regular application; fatal (system) exceptions should always be caught at the \"top\". In other words, the code that executes Hibernate calls (in the persistence layer) and the code that handles <literal>RuntimeException</literal> (and usually can only clean up and exit) are in different layers. The current context management by Hibernate can significantly simplify this design, as all you need is access to a <literal>SessionFactory</literal>. Exception handling is discussed later in this chapter."
msgstr ""

#: transactions.xml:479(para) 
msgid "Note that you should select <literal>org.hibernate.transaction.JDBCTransactionFactory</literal> (which is the default), and for the second example <literal>\"thread\"</literal> as your <literal>hibernate.current_session_context_class</literal>."
msgstr ""

#: transactions.xml:488(title) 
msgid "Using JTA"
msgstr ""

#: transactions.xml:490(para) 
msgid "If your persistence layer runs in an application server (e.g. behind EJB session beans), every datasource connection obtained by Hibernate will automatically be part of the global JTA transaction. You can also install a standalone JTA implementation and use it without EJB. Hibernate offers two strategies for JTA integration."
msgstr ""

#: transactions.xml:497(para) 
msgid "If you use bean-managed transactions (BMT) Hibernate will tell the application server to start and end a BMT transaction if you use the <literal>Transaction</literal> API. So, the transaction management code is identical to the non-managed environment."
msgstr ""

#: transactions.xml:522(para) 
msgid "If you want to use a transaction-bound <literal>Session</literal>, that is, the <literal>getCurrentSession()</literal> functionality for easy context propagation, you will have to use the JTA <literal>UserTransaction</literal> API directly:"
msgstr ""

#: transactions.xml:546(para) 
msgid "With CMT, transaction demarcation is done in session bean deployment descriptors, not programatically, hence, the code is reduced to:"
msgstr ""

#: transactions.xml:558(para) 
msgid "In a CMT/EJB even rollback happens automatically, since an unhandled <literal>RuntimeException</literal> thrown by a session bean method tells the container to set the global transaction to rollback. <emphasis>This means you do not need to use the Hibernate <literal>Transaction</literal> API at all with BMT or CMT, and you get automatic propagation of the \"current\" Session bound to the transaction.</emphasis>"
msgstr ""

#: transactions.xml:566(para) 
msgid "Note that you should choose <literal>org.hibernate.transaction.JTATransactionFactory</literal> if you use JTA directly (BMT), and <literal>org.hibernate.transaction.CMTTransactionFactory</literal> in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set <literal>hibernate.transaction.manager_lookup_class</literal>. Furthermore, make sure that your <literal>hibernate.current_session_context_class</literal> is either unset (backwards compatiblity), or set to <literal>\"jta\"</literal>."
msgstr ""

#: transactions.xml:575(para) 
msgid "The <literal>getCurrentSession()</literal> operation has one downside in a JTA environment. There is one caveat to the use of <literal>after_statement</literal> connection release mode, which is then used by default. Due to a silly limitation of the JTA spec, it is not possible for Hibernate to automatically clean up any unclosed <literal>ScrollableResults</literal> or <literal>Iterator</literal> instances returned by <literal>scroll()</literal> or <literal>iterate()</literal>. You <emphasis>must</emphasis> release the underlying database cursor by calling <literal>ScrollableResults.close()</literal> or <literal>Hibernate.close(Iterator)</literal> explicity from a <literal>finally</literal> block. (Of course, most applications can easily avoid using <literal>scroll()</literal> or <literal>iterate()</literal> at all from the JTA or CMT code.)"
msgstr ""

#: transactions.xml:591(title) 
msgid "Exception handling"
msgstr ""

#: transactions.xml:593(para) 
msgid "If the <literal>Session</literal> throws an exception (including any <literal>SQLException</literal>), you should immediately rollback the database transaction, call <literal>Session.close()</literal> and discard the <literal>Session</literal> instance. Certain methods of <literal>Session</literal> will <emphasis>not</emphasis> leave the session in a consistent state. No exception thrown by Hibernate can be treated as recoverable. Ensure that the <literal>Session</literal> will be closed by calling <literal>close()</literal> in a <literal>finally</literal> block."
msgstr ""

#: transactions.xml:604(para) 
msgid "The <literal>HibernateException</literal>, which wraps most of the errors that can occur in a Hibernate persistence layer, is an unchecked exception (it wasn't in older versions of Hibernate). In our opinion, we shouldn't force the application developer to catch an unrecoverable exception at a low layer. In most systems, unchecked and fatal exceptions are handled in one of the first frames of the method call stack (i.e. in higher layers) and an error message is presented to the application user (or some other appropriate action is taken). Note that Hibernate might also throw other unchecked exceptions which are not a <literal>HibernateException</literal>. These are, again, not recoverable and appropriate action should be taken."
msgstr ""

#: transactions.xml:616(para) 
msgid "Hibernate wraps <literal>SQLException</literal>s thrown while interacting with the database in a <literal>JDBCException</literal>. In fact, Hibernate will attempt to convert the eexception into a more meningful subclass of <literal>JDBCException</literal>. The underlying <literal>SQLException</literal> is always available via <literal>JDBCException.getCause()</literal>. Hibernate converts the <literal>SQLException</literal> into an appropriate <literal>JDBCException</literal> subclass using the <literal>SQLExceptionConverter</literal> attached to the <literal>SessionFactory</literal>. By default, the <literal>SQLExceptionConverter</literal> is defined by the configured dialect; however, it is also possible to plug in a custom implementation (see the javadocs for the <literal>SQLExceptionConverterFactory</literal> class for details). The standard <literal>JDBCException</literal> subtypes are:"
msgstr ""

#: transactions.xml:632(para) 
msgid "<literal>JDBCConnectionException</literal> - indicates an error with the underlying JDBC communication."
msgstr ""

#: transactions.xml:638(para) 
msgid "<literal>SQLGrammarException</literal> - indicates a grammar or syntax problem with the issued SQL."
msgstr ""

#: transactions.xml:644(para) 
msgid "<literal>ConstraintViolationException</literal> - indicates some form of integrity constraint violation."
msgstr ""

#: transactions.xml:650(para) 
msgid "<literal>LockAcquisitionException</literal> - indicates an error acquiring a lock level necessary to perform the requested operation."
msgstr ""

#: transactions.xml:656(para) 
msgid "<literal>GenericJDBCException</literal> - a generic exception which did not fall into any of the other categories."
msgstr ""

#: transactions.xml:666(title) 
msgid "Transaction timeout"
msgstr ""

#: transactions.xml:668(para) 
msgid "One extremely important feature provided by a managed environment like EJB that is never provided for non-managed code is transaction timeout. Transaction timeouts ensure that no misbehaving transaction can indefinitely tie up resources while returning no response to the user. Outside a managed (JTA) environment, Hibernate cannot fully provide this functionality. However, Hibernate can at least control data access operations, ensuring that database level deadlocks and queries with huge result sets are limited by a defined timeout. In a managed environment, Hibernate can delegate transaction timeout to JTA. This functioanlity is abstracted by the Hibernate <literal>Transaction</literal> object."
msgstr ""

#: transactions.xml:701(para) 
msgid "Note that <literal>setTimeout()</literal> may not be called in a CMT bean, where transaction timeouts must be defined declaratively."
msgstr ""

#: transactions.xml:711(title) 
msgid "Optimistic concurrency control"
msgstr ""

#: transactions.xml:713(para) 
msgid "The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning. Version checking uses version numbers, or timestamps, to detect conflicting updates (and to prevent lost updates). Hibernate provides for three possible approaches to writing application code that uses optimistic concurrency. The use cases we show are in the context of long conversations, but version checking also has the benefit of preventing lost updates in single database transactions."
msgstr ""

#: transactions.xml:724(title) 
msgid "Application version checking"
msgstr ""

#: transactions.xml:726(para) 
msgid "In an implementation without much help from Hibernate, each interaction with the database occurs in a new <literal>Session</literal> and the developer is responsible for reloading all persistent instances from the database before manipulating them. This approach forces the application to carry out its own version checking to ensure conversation transaction isolation. This approach is the least efficient in terms of database access. It is the approach most similar to entity EJBs."
msgstr ""

#: transactions.xml:747(para) 
msgid "The <literal>version</literal> property is mapped using <literal>&lt;version&gt;</literal>, and Hibernate will automatically increment it during flush if the entity is dirty."
msgstr ""

#: transactions.xml:753(para) 
msgid "Of course, if you are operating in a low-data-concurrency environment and don't require version checking, you may use this approach and just skip the version check. In that case, <emphasis>last commit wins</emphasis> will be the default strategy for your long conversations. Keep in mind that this might confuse the users of the application, as they might experience lost updates without error messages or a chance to merge conflicting changes."
msgstr ""

#: transactions.xml:762(para) 
msgid "Clearly, manual version checking is only feasible in very trivial circumstances and not practical for most applications. Often not only single instances, but complete graphs of modified ojects have to be checked. Hibernate offers automatic version checking with either an extended <literal>Session</literal> or detached instances as the design paradigm."
msgstr ""

#: transactions.xml:773(title) 
msgid "Extended session and automatic versioning"
msgstr ""