transactions.pot

hibernate-distribution-3.3.1.GA-dist.zip源码

msgstr ""

#. Tag: programlisting
#: transactions.xml:513
#, no-c-format
msgid ""
      "<![CDATA[// CMT idiom\n"
      " Session sess = factory.getCurrentSession();\n"
      "\n"
      " // do some work\n"
      " ...\n"
      "]]>"
msgstr ""

#. Tag: para
#: transactions.xml:515
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:523
#, no-c-format
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 compatibility), or set to <literal>\"jta\"</literal>."
msgstr ""

#. Tag: para
#: transactions.xml:532
#, no-c-format
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> explicitly 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 ""

#. Tag: title
#: transactions.xml:548
#, no-c-format
msgid "Exception handling"
msgstr ""

#. Tag: para
#: transactions.xml:550
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:561
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:573
#, no-c-format
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 exception into a more meaningful 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 ""

#. Tag: para
#: transactions.xml:589
#, no-c-format
msgid "<literal>JDBCConnectionException</literal> - indicates an error with the underlying JDBC communication."
msgstr ""

#. Tag: para
#: transactions.xml:595
#, no-c-format
msgid "<literal>SQLGrammarException</literal> - indicates a grammar or syntax problem with the issued SQL."
msgstr ""

#. Tag: para
#: transactions.xml:601
#, no-c-format
msgid "<literal>ConstraintViolationException</literal> - indicates some form of integrity constraint violation."
msgstr ""

#. Tag: para
#: transactions.xml:607
#, no-c-format
msgid "<literal>LockAcquisitionException</literal> - indicates an error acquiring a lock level necessary to perform the requested operation."
msgstr ""

#. Tag: para
#: transactions.xml:613
#, no-c-format
msgid "<literal>GenericJDBCException</literal> - a generic exception which did not fall into any of the other categories."
msgstr ""

#. Tag: title
#: transactions.xml:623
#, no-c-format
msgid "Transaction timeout"
msgstr ""

#. Tag: para
#: transactions.xml:625
#, no-c-format
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 functionality is abstracted by the Hibernate <literal>Transaction</literal> object."
msgstr ""

#. Tag: programlisting
#: transactions.xml:638
#, no-c-format
msgid ""
      "<![CDATA[\n"
      "Session sess = factory.openSession();\n"
      "try {\n"
      "    //set transaction timeout to 3 seconds\n"
      "    sess.getTransaction().setTimeout(3);\n"
      "    sess.getTransaction().begin();\n"
      "\n"
      "    // do some work\n"
      "    ...\n"
      "\n"
      "    sess.getTransaction().commit()\n"
      "}\n"
      "catch (RuntimeException e) {\n"
      "    sess.getTransaction().rollback();\n"
      "    throw e; // or display error message\n"
      "}\n"
      "finally {\n"
      "    sess.close();\n"
      "}]]>"
msgstr ""

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

#. Tag: title
#: transactions.xml:650
#, no-c-format
msgid "Optimistic concurrency control"
msgstr ""

#. Tag: para
#: transactions.xml:652
#, no-c-format
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 ""

#. Tag: title
#: transactions.xml:663
#, no-c-format
msgid "Application version checking"
msgstr ""

#. Tag: para
#: transactions.xml:665
#, no-c-format
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 ""

#. Tag: programlisting
#: transactions.xml:674
#, no-c-format
msgid ""
      "<![CDATA[// foo is an instance loaded by a previous Session\n"
      "session = factory.openSession();\n"
      "Transaction t = session.beginTransaction();\n"
      "\n"
      "int oldVersion = foo.getVersion();\n"
      "session.load( foo, foo.getKey() ); // load the current state\n"
      "if ( oldVersion != foo.getVersion() ) throw new StaleObjectStateException();\n"
      "foo.setProperty(\"bar\");\n"
      "\n"
      "t.commit();\n"
      "session.close();]]>"
msgstr ""

#. Tag: para
#: transactions.xml:676
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:682
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:691
#, no-c-format
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 objects have to be checked. Hibernate offers automatic version checking with either an extended <literal>Session</literal> or detached instances as the design paradigm."
msgstr ""

#. Tag: title
#: transactions.xml:702
#, no-c-format
msgid "Extended session and automatic versioning"
msgstr ""

#. Tag: para
#: transactions.xml:704
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:713
#, no-c-format
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 ""

#. Tag: programlisting
#: transactions.xml:721
#, no-c-format
msgid ""
      "<![CDATA[// foo is an instance loaded earlier by the old session\n"
      "Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction\n"
      "\n"
      "foo.setProperty(\"bar\");\n"
      "\n"
      "session.flush();    // Only for last transaction in conversation\n"
      "t.commit();         // Also return JDBC connection\n"
      "session.close();    // Only for last transaction in conversation]]>"
msgstr ""

#. Tag: para
#: transactions.xml:722
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:737
#, no-c-format
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 ""

#. Tag: para
#: transactions.xml:747
#, no-c-format
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 ""