transactions.pot

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

#. Tag: para
#: transactions.xml:322
#, no-c-format
msgid "Never use the anti-patterns <emphasis>session-per-user-session</emphasis> or <emphasis>session-per-application</emphasis> (of course, there are rare exceptions to this rule). Note that some of the following issues might also appear with the recommended patterns, make sure you understand the implications before making a design decision:"
msgstr ""

#. Tag: para
#: transactions.xml:331
#, no-c-format
msgid "A <literal>Session</literal> is not thread-safe. Things which are supposed to work concurrently, like HTTP requests, session beans, or Swing workers, will cause race conditions if a <literal>Session</literal> instance would be shared. If you keep your Hibernate <literal>Session</literal> in your <literal>HttpSession</literal> (discussed later), you should consider synchronizing access to your Http session. Otherwise, a user that clicks reload fast enough may use the same <literal>Session</literal> in two concurrently running threads."
msgstr ""

#. Tag: para
#: transactions.xml:342
#, no-c-format
msgid "An exception thrown by Hibernate means you have to rollback your database transaction and close the <literal>Session</literal> immediately (discussed later in more detail). If your <literal>Session</literal> is bound to the application, you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction. This means the database state and the business objects do get out of sync. Usually this is not a problem, because exceptions are not recoverable and you have to start over after rollback anyway."
msgstr ""

#. Tag: para
#: transactions.xml:354
#, no-c-format
msgid "The <literal>Session</literal> caches every object that is in persistent state (watched and checked for dirty state by Hibernate). This means it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data. One solution for this is to call <literal>clear()</literal> and <literal>evict()</literal> to manage the <literal>Session</literal> cache, but you most likely should consider a Stored Procedure if you need mass data operations. Some solutions are shown in <xref linkend=\"batch\"/>. Keeping a <literal>Session</literal> open for the duration of a user session also means a high probability of stale data."
msgstr ""

#. Tag: title
#: transactions.xml:372
#, no-c-format
msgid "Database transaction demarcation"
msgstr ""

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

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

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

#. Tag: para
#: transactions.xml:403
#, no-c-format
msgid "Usually, ending a <literal>Session</literal> involves four distinct phases:"
msgstr ""

#. Tag: para
#: transactions.xml:409
#, no-c-format
msgid "flush the session"
msgstr ""

#. Tag: para
#: transactions.xml:414
#, no-c-format
msgid "commit the transaction"
msgstr ""

#. Tag: para
#: transactions.xml:419
#, no-c-format
msgid "close the session"
msgstr ""

#. Tag: para
#: transactions.xml:424
#, no-c-format
msgid "handle exceptions"
msgstr ""

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

#. Tag: title
#: transactions.xml:437
#, no-c-format
msgid "Non-managed environment"
msgstr ""

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

#. Tag: programlisting
#: transactions.xml:446
#, no-c-format
msgid ""
      "<![CDATA[// Non-managed environment idiom\n"
      "Session sess = factory.openSession();\n"
      "Transaction tx = null;\n"
      "try {\n"
      "    tx = sess.beginTransaction();\n"
      "\n"
      "    // do some work\n"
      "    ...\n"
      "\n"
      "    tx.commit();\n"
      "}\n"
      "catch (RuntimeException e) {\n"
      "    if (tx != null) tx.rollback();\n"
      "    throw e; // or display error message\n"
      "}\n"
      "finally {\n"
      "    sess.close();\n"
      "}]]>"
msgstr ""

#. Tag: para
#: transactions.xml:448
#, no-c-format
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 <link linkend=\"objectstate-flushing\">FlushMode</link> 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 ""

#. Tag: para
#: transactions.xml:457
#, no-c-format
msgid "A much more flexible solution is Hibernate's built-in \"current session\" context management, as described earlier:"
msgstr ""

#. Tag: programlisting
#: transactions.xml:462
#, no-c-format
msgid ""
      "<![CDATA[// Non-managed environment idiom with getCurrentSession()\n"
      "try {\n"
      "    factory.getCurrentSession().beginTransaction();\n"
      "\n"
      "    // do some work\n"
      "    ...\n"
      "\n"
      "    factory.getCurrentSession().getTransaction().commit();\n"
      "}\n"
      "catch (RuntimeException e) {\n"
      "    factory.getCurrentSession().getTransaction().rollback();\n"
      "    throw e; // or display error message\n"
      "}]]>"
msgstr ""

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

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

#. Tag: title
#: transactions.xml:483
#, no-c-format
msgid "Using JTA"
msgstr ""

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

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

#. Tag: programlisting
#: transactions.xml:498
#, no-c-format
msgid ""
      "<![CDATA[// BMT idiom\n"
      "Session sess = factory.openSession();\n"
      "Transaction tx = null;\n"
      "try {\n"
      "    tx = sess.beginTransaction();\n"
      "\n"
      "    // do some work\n"
      "    ...\n"
      "\n"
      "    tx.commit();\n"
      "}\n"
      "catch (RuntimeException e) {\n"
      "    if (tx != null) tx.rollback();\n"
      "    throw e; // or display error message\n"
      "}\n"
      "finally {\n"
      "    sess.close();\n"
      "}]]>"
msgstr ""

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

#. Tag: programlisting
#: transactions.xml:506
#, no-c-format
msgid ""
      "<![CDATA[// BMT idiom with getCurrentSession()\n"
      "try {\n"
      "    UserTransaction tx = (UserTransaction)new InitialContext()\n"
      "                            .lookup(\"java:comp/UserTransaction\");\n"
      "\n"
      "    tx.begin();\n"
      "\n"
      "    // Do some work on Session bound to transaction\n"
      "    factory.getCurrentSession().load(...);\n"
      "    factory.getCurrentSession().persist(...);\n"
      "\n"
      "    tx.commit();\n"
      "}\n"
      "catch (RuntimeException e) {\n"
      "    tx.rollback();\n"
      "    throw e; // or display error message\n"
      "}]]>"
msgstr ""

#. Tag: para
#: transactions.xml:508
#, no-c-format
msgid "With CMT, transaction demarcation is done in session bean deployment descriptors, not programmatically, hence, the code is reduced to:"