Hibernate example source code file (transactions.po)

This example Hibernate source code file (transactions.po) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - Hibernate tags/keywords

a, cmt, ejb, hibernate, hibernate, in, jdbc, jta, jta, tag, tag, the, the, this

The Hibernate transactions.po source code

# translation of Collection_Mapping.po to
# Xi HUANG <xhuang@redhat.com>, 2007, 2010.
msgid ""
msgstr ""
"Project-Id-Version: Collection_Mapping\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2010-02-11T05:38:16\n"
"PO-Revision-Date: 2010-01-13 11:23+1000\n"
"Last-Translator: Xi HUANG <xhuang@redhat.com>\n"
"Language-Team:  <en@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"

#. Tag: title
#, fuzzy, no-c-format
msgid "Transactions and Concurrency"
msgstr "トランザクションと並行性"

#. Tag: para
#, no-c-format
msgid ""
"The most important point about Hibernate and concurrency control is that it "
"is easy to understand. Hibernate directly uses JDBC connections and JTA "
"resources without adding any additional locking behavior. It is recommended "
"that you spend some time with the JDBC, ANSI, and transaction isolation "
"specification of your database management system."
msgstr ""
"Hibernate と同時実行制御について最も重要な点は、容易に理解できることです。 "
"Hibernate は新たなロックの振る舞いを追加しておらず、直接 JDBC コネクションと "
"JTA リソースを使用します。 JDBC 、 ANSI 、およびデータベース管理システム"
"（DBMS）のトランザクション分離の仕様を少し時間をかけて勉強することを強く推奨"
"します。"

#. Tag: para
#, no-c-format
msgid ""
"Hibernate does not lock objects in memory. Your application can expect the "
"behavior as defined by the isolation level of your database transactions. "
"Through <literal>Session, which is also a transaction-scoped "
"cache, Hibernate provides repeatable reads for lookup by identifier and "
"entity queries and not reporting queries that return scalar values."
msgstr ""
"Hibernate はメモリ内のオブジェクトをロックしません。アプリケーションは、デー"
"タベーストランザクションの分離レベルで定義した振る舞いを期待できます。トラン"
"ザクションスコープのキャッシュでもある <literal>Session のお陰で、"
"識別子やクエリにより検索したエンティティはリピータブルリードになります（スカ"
"ラー値を返すようなレポートクエリは違います）。"

#. Tag: para
#, no-c-format
msgid ""
"In addition to versioning for automatic optimistic concurrency control, "
"Hibernate also offers, using the <literal>SELECT FOR UPDATE "
"syntax, a (minor) API for pessimistic locking of rows. Optimistic "
"concurrency control and this API are discussed later in this chapter."
msgstr ""
"バージョニングによる自動的な楽観的同時実行制御に加えて、 <literal>SELECT FOR "
"UPDATE</literal> 文を使用して、行を悲観的ロックするための（マイナーな） API "
"も提供します。楽観的同時実行制御とこの API については、この章の後のほうで議論"
"します。"

#. Tag: para
#, no-c-format
msgid ""
"The discussion of concurrency control in Hibernate begins with the "
"granularity of <literal>Configuration, SessionFactorySession, as well as database transactions "
"and long conversations."
msgstr ""
"データベーストランザクションや長い対話（conversation、ロングトランザクショ"
"ン）だけでなく、 <literal>Configuration、SessionFactorySession という粒度で Hibernate が行う同時"
"実行制御の議論を始めます。"

#. Tag: title
#, no-c-format
msgid "Session and transaction scopes"
msgstr "session スコープと transaction スコープ"

#. Tag: para
#, no-c-format
msgid ""
"A <literal>SessionFactory is an expensive-to-create, threadsafe "
"object, intended to be shared by all application threads. It is created "
"once, usually on application startup, from a <literal>Configuration は生成することが高価で、スレッドセーフなオ"
"ブジェクトです。よって、アプリケーションのすべてのスレッドで共有すべきです。"
"通常、アプリケーションの起動時に、 <literal>Configuration インスタ"
"ンスから１度だけ生成します。"

#. Tag: para
#, no-c-format
msgid ""
"A <literal>Session is an inexpensive, non-threadsafe object that "
"should be used once and then discarded for: a single request, a conversation "
"or a single unit of work. A <literal>Session will not obtain a "
"JDBC <literal>Connection, or a Datasource, "
"unless it is needed. It will not consume any resources until used."
msgstr ""
"<literal>Session は高価ではなく、スレッドセーフなオブジェクトでもあ"
"りません。よって、１つの要求や１つの対話、１つの作業単位（unit of work）に対"
"して１度だけ使い、その後で捨てるべきです。 <literal>Session は必要"
"になるまで、 JDBC <literal>Connection（もしくは "
"<literal>DataSource）を獲得しません。ゆえに、実際に使用するときまで"
"リソースを消費しません。"

#. Tag: para
#, no-c-format
msgid ""
"In order to reduce lock contention in the database, a database transaction "
"has to be as short as possible. Long database transactions will prevent your "
"application from scaling to a highly concurrent load. It is not recommended "
"that you hold a database transaction open during user think time until the "
"unit of work is complete."
msgstr ""
"この状況を完了させるために、データベーストランザクションについても考えなけれ"
"ばなりません。データベース内のロックの競合を少なくするために、データベースト"
"ランザクションは可能な限り短くするべきです。長いデータベーストランザクション"
"は、アプリケーションの高い並列実行性を阻害します。ゆえに、ユーザーが考えてい"
"る間（作業単位が完了するまで）データベーストランザクションを開いたままにする"
"のは、たいていの場合よい設計とはいえません。"

#. Tag: para
#, no-c-format
msgid ""
"What is the scope of a unit of work? Can a single Hibernate "
"<literal>Session span several database transactions, or is this a "
"one-to-one relationship of scopes? When should you open and close a "
"<literal>Session and how do you demarcate the database transaction "
"boundaries? These questions are addressed in the following sections."
msgstr ""
"作業単位というスコープとは何でしょうか？１つの Hibernate <literal>SessionPoEAA antipattern: do "
"not open and close a <literal>Session for every simple database "
"call in a single thread. The same is true for database transactions. "
"Database calls in an application are made using a planned sequence; they are "
"grouped into atomic units of work. This also means that auto-commit after "
"every single SQL statement is useless in an application as this mode is "
"intended for ad-hoc SQL console work. Hibernate disables, or expects the "
"application server to disable, auto-commit mode immediately. Database "
"transactions are never optional. All communication with a database has to "
"occur inside a transaction. Auto-commit behavior for reading data should be "
"avoided, as many small transactions are unlikely to perform better than one "
"clearly defined unit of work. The latter is also more maintainable and "
"extensible."
msgstr ""
"１つ目は、 <emphasis>session-per-operation アンチパターンを使って"
"はいけません。すなわち、１つのスレッドの中で、単純なデータベース呼び出しの度"
"に <literal>Session を開いて、閉じてはいけません。もちろん、データ"
"ベーストランザクションについても同様です。アプリケーション中のデータベース呼"
"び出しは、計画されたシーケンス（planned sequence）を使い、アトミックな作業単"
"位に分類されます。（１つの SQL 文ごとにコミットする自動コミットが、使われない"
"という意味でもあることに注意してください。自動コミットは、 SQL コンソールでア"
"ドホックな作業をする際に使うものです。 Hibernate は直ちに自動コミットモードを"
"無効にします。もしくは、アプリケーションサーバーが無効化することを期待しま"
"す。）データベーストランザクションはオプションではありません。データベースと"
"のすべての通信は、データの読み込みであっても、書き込みであっても、トランザク"
"ションの中で行わなければなりません。説明すると、データ読み込みに対して、自動"
"コミットは避けるべきです。なぜなら、多数の小さなトランザクションは、明確に定"
"義された１つの作業単位と比べて、パフォーマンスがよくなることはありません。後"
"者は保守性や拡張性もよりすぐれています。"

#. Tag: para
#, no-c-format
msgid ""
"The most common pattern in a multi-user client/server application is "
"<emphasis>session-per-request. In this model, a request from the "
"client is sent to the server, where the Hibernate persistence layer runs. A "
"new Hibernate <literal>Session is opened, and all database "
"operations are executed in this unit of work. On completion of the work, and "
"once the response for the client has been prepared, the session is flushed "
"and closed. Use a single database transaction to serve the clients request, "
"starting and committing it when you open and close the <literal>Session です。このモデルの中"
"では、クライアントから（ Hibernate 永続化層が動作する）サーバーへリクエストが"
"送られ、新しい Hibernate <literal>Session が開かれます。そして、こ"
"の作業単位の中ですべてのデータベース処理が実行されます。作業が完了した（そし"
"て、クライアントへのレスポンスが準備できた）時点で、 session をフラッシュし、"
"閉じます。クライアントの要求を処理するために、１つのデータベーストランザク"
"ションを使用するでしょう。 <literal>Session を開き、閉じる際に、"
"データベーストランザクションを開始し、コミットします。二つの関係は一対一で"
"す。このモデルは多くのアプリケーションに完全に適合します。"

#. Tag: para
#, no-c-format
msgid ""
"The challenge lies in the implementation. Hibernate provides built-in "
"management of the \"current session\" to simplify this pattern. Start a "
"transaction when a server request has to be processed, and end the "
"transaction before the response is sent to the client. Common solutions are "
"<literal>ServletFilter, AOP interceptor with a pointcut on the "
"service methods, or a proxy/interception container. An EJB container is a "
"standardized way to implement cross-cutting aspects such as transaction "
"demarcation on EJB session beans, declaratively with CMT. If you use "
"programmatic transaction demarcation, for ease of use and code portability "
"use the Hibernate <literal>Transaction API shown later in this "
"chapter."
msgstr ""
"以降の実装にチャレンジしてください。 Hibernate は単純なこのパターンのために、"
"予め組み込まれた \"current session\" の管理を提供します。サーバーリクエストを"
"処理する際はトランザクションを開始しなければなりません。そして、レスポンスを"
"クライアントに送信する前にトランザクションを終わらせます。好きな方法で実現で"
"きます。一般的な解決策は <literal>ServletFilter やサービスメソッド"
"をポイントカットして AOP インターセプター、 proxy/interception コンテナで"
"す。 EJB コンテナは EJB セッション Bean をトランザクション境界としてアスペク"
"トをクロスカットする実装の標準的な方法です（ CMT による宣言的）。プログラムに"
"よるトランザクション境界を使うと決めた場合、簡単に使うため、互換性のあるコー"
"ドにするために、この章の後のほうにある Hibernate <literal>Transaction. "
"You will always get a <literal>Session scoped to the current "
"database transaction. This has to be configured for either resource-local or "
"JTA environments, see <xref linkend=\"architecture-current-session\" />."
msgstr ""
"アプリケーションのコードは、必要なときにどこでも、何回でも、単に "
"<literal>sessionFactory.getCurrentSession() を呼び出すだけで「現在"
"のセッション」にアクセスできます。現在のデータベーストランザクションへの "
"<literal>セッション を常に取得します。リソースローカルな環境、もし"
"くは JTA 環境を構成しなければなりません （<xref linkend=\"architecture-"
"current-session\"/> を参照してください）。"

#. Tag: para
#, no-c-format
msgid ""
"You can extend the scope of a <literal>Session and database "
"transaction until the \"view has been rendered\". This is especially useful "
"in servlet applications that utilize a separate rendering phase after the "
"request has been processed. Extending the database transaction until view "
"rendering, is achieved by implementing your own interceptor. However, this "
"will be difficult if you rely on EJBs with container-managed transactions. A "
"transaction will be completed when an EJB method returns, before rendering "
"of any view can start. See the Hibernate website and forum for tips and "
"examples relating to this <emphasis>Open Session in View pattern."
msgstr ""
"ときどき、「ビューを描画する」まで <literal>セッション とデータベー"
"ストランザクションのスコープを拡張すると便利なことがあります。これは、要求の"
"処理と描画のフェーズを分けているサーブレットアプリケーションにおいて特に役立"
"ちます。独自のインターセプタを実装すれば、ビューを描画するまでデータベースト"
"ランザクションを拡張するのは簡単です。しかし、コンテナ管理トランザクションの "
"EJB に頼る場合は、簡単にはできません。なぜなら、ビューの描画を開始する前に、 "
"EJB のメソッドがリターンした際に、トランザクションが完了するためです。この "
"<emphasis>Open Session in View パターンに関連するヒントと例につい"
"ては、 Hibernate の Web サイトやフォーラムを参照してください。"

#. Tag: title
#, no-c-format
msgid "Long conversations"
msgstr "長い対話"

#. Tag: para
#, no-c-format
msgid ""
"The session-per-request pattern is not the only way of designing units of "
"work. Many business processes require a whole series of interactions with "
"the user that are interleaved with database accesses. In web and enterprise "
"applications, it is not acceptable for a database transaction to span a user "
"interaction. Consider the following example:"
msgstr ""
"session-per-request パターンは、作業単位を設計する際に役立つ考えというだけで"
"はありません。多くのビジネスプロセスは、ユーザーとの一連の相互作用全体を要求"
"します。その相互作用には、データベースアクセスが含まれます。 Web とエンタープ"
"ライズアプリケーションでは、データベーストランザクションがユーザーとの相互作"
"用にまで渡ることは許されません。次の例をよく考えてみてください: "

#. Tag: para
#, no-c-format
msgid ""
"The first screen of a dialog opens. The data seen by the user has been "
"loaded in a particular <literal>Session and database transaction. "
"The user is free to modify the objects."
msgstr ""
"ダイアログの最初の画面が開き、個々の <literal>Session とデータベー"
"ストランザクションの中でロードされたデータをユーザーに見せます。ユーザーはオ"
"ブジェクトを自由に修正できます。"

#. Tag: para
#, no-c-format
msgid ""
"The user clicks \"Save\" after 5 minutes and expects their modifications to "
"be made persistent. The user also expects that they were the only person "
"editing this information and that no conflicting modification has occurred."
msgstr ""
"5分後にユーザーは \"Save\" をクリックし、修正が永続化されるのを期待します。ま"
"た、この情報を編集したのは自分１人だけで、修正のコンフリクトは発生しないと期"
"待します。"

#. Tag: para
#, no-c-format
msgid ""
"From the point of view of the user, we call this unit of work a long-running "
"<emphasis>conversation or application transaction （もしく"
"は、<emphasis>アプリケーショントランザクション ）と呼びます。アプ"
"リケーションにこれを実装する方法はたくさんあります。"

#. Tag: para
#, no-c-format
msgid ""
"A first naive implementation might keep the <literal>Session and "
"database transaction open during user think time, with locks held in the "
"database to prevent concurrent modification and to guarantee isolation and "
"atomicity. This is an anti-pattern, since lock contention would not allow "
"the application to scale with the number of concurrent users."
msgstr ""
"最初に思いつく実装は、ユーザーが考えている間、 <literal>Session と"
"データベーストランザクションを開いたままにしておくことです。同時に修正され"
"ず、分離と原子性が保証されるように、データベース内のロックは保持したままにし"
"ます。もちろん、これはアンチパターンです。なぜなら、ロックの競合が発生する"
"と、アプリケーションが同時ユーザー数に応じてスケールアップできなくなるからで"
"す。"

#. Tag: para
#, no-c-format
msgid ""
"You have to use several database transactions to implement the conversation. "
"In this case, maintaining isolation of business processes becomes the "
"partial responsibility of the application tier. A single conversation "
"usually spans several database transactions. It will be atomic if only one "
"of these database transactions (the last one) stores the updated data. All "
"others simply read data (for example, in a wizard-style dialog spanning "
"several request/response cycles). This is easier to implement than it might "
"sound, especially if you utilize some of Hibernate's features:"
msgstr ""
"明らかに、対話を実装するためには、いくつかのデータベーストランザクションを使"
"用するべきです。この場合、ビジネスプロセスの分離を維持することは、アプリケー"
"ション層の責務の１つになります。１つの対話は、通常いくつかのデータベーストラ"
"ンザクションに及びます。データベーストランザクションの１つのみ（最後の１つ）"
"が更新したデータを保存し、他はデータを読むだけであれば、それはアトミックです"
"（例えば、いくつかの要求／応答を繰り返すウィザード形式のダイアログ）。これは"
"聞くより、実装したほうが簡単です。 Hibernate の機能を使うのであれば、特に簡単"
"です:"

#. Tag: para
#, no-c-format
msgid ""
"<emphasis>Automatic Versioning: Hibernate can perform automatic "
"optimistic concurrency control for you. It can automatically detect if a "
"concurrent modification occurred during user think time. Check for this at "
"the end of the conversation."
msgstr ""
"<emphasis>自動バージョニング - Hibernate は自動的に楽観的同時実行"
"制御ができます。ユーザーが考えている間に同時に修正がおきた場合、自動的に検出"
"できます。通常、対話の終了時にチェックするだけです。"

#. Tag: para
#, no-c-format
msgid ""
"<emphasis>Detached Objects: if you decide to use the "
"<emphasis>session-per-request pattern, all loaded instances will "
"be in the detached state during user think time. Hibernate allows you to "
"reattach the objects and persist the modifications. The pattern is called "
"<emphasis>session-per-request-with-detached-objects. Automatic "
"versioning is used to isolate concurrent modifications."
msgstr ""
"<emphasis>分離（Detached）オブジェクト - すでに議論した "
"<emphasis>session-per-request パターンを使うと決定した場合、ロード"
"されたすべてのインスタンスは、ユーザーが考えている間は、セッションから分離さ"
"れた状態になります。オブジェクトをセッションに再追加し、修正を永続化できま"
"す。これを <emphasis>session-per-request-with-detached-objects パ"
"ターンと呼びます。自動バージョニングを使うことで、同時に行われる修正を分離で"
"きます。"

#. Tag: para
#, no-c-format
msgid ""
"<emphasis>Extended (or Long) Session: the Hibernate "
"<literal>Session can be disconnected from the underlying JDBC "
"connection after the database transaction has been committed and reconnected "
"when a new client request occurs. This pattern is known as <emphasis>session-"
"per-conversation</emphasis> and makes even reattachment unnecessary. "
"Automatic versioning is used to isolate concurrent modifications and the "
"<literal>Session will not be allowed to be flushed automatically, "
"but explicitly."
msgstr ""
"<emphasis>拡張（もしくは、長い）セッション - Hibernate の "
"<literal>Session は、データベーストランザクションをコミットした後、"
"裏で結びついている JDBC コネクションを切断できます。そして、クライアントから"
"の新しい要求が発生した際に、再接続できます。このパターンは、 "
"<emphasis>session-per-conversation という名で知られており、オブ"
"ジェクトをセッションへ再追加することさえ不要にします。自動バージョニングを使"
"うことで、同時に行われる修正を分離できます。通常 <literal>Session "
"を自動的にフラッシュさせず、明示的にフラッシュします。"

#. Tag: para
#, no-c-format
msgid ""
"Both <emphasis>session-per-request-with-detached-objects and "
"<emphasis>session-per-conversation have advantages and "
"disadvantages. These disadvantages are discussed later in this chapter in "
"the context of optimistic concurrency control."
msgstr ""
"<emphasis>session-per-request-with-detached-objects と "
"<emphasis>session-per-conversation の２つは、利点と欠点を持ってい"
"ます。これについては、この章の後のほうで、楽観的同時実行制御の文脈の中で議論"
"します。"

#. Tag: title
#, no-c-format
msgid "Considering object identity"
msgstr "オブジェクト識別子を考える"

#. Tag: para
#, no-c-format
msgid ""
"An application can concurrently access the same persistent state in two "
"different <literal>Sessions. However, an instance of a persistent "
"class is never shared between two <literal>Session instances. It "
"is for this reason that there are two different notions of identity:"
msgstr ""
"アプリケーションは、２つの異なる <literal>Session から同じ永続状態"
"に同時にアクセスできます。しかし、２つの <literal>Session インスタ"
"ンスが永続性クラスの１つのインスタンスを共有することはできません。ゆえに、識"
"別子には２つの異なる概念があるということになります。"

#. Tag: term
#, no-c-format
msgid "Database Identity"
msgstr "データベース識別子"

#. Tag: para
#, fuzzy, no-c-format
msgid "<literal>foo.getId().equals( bar.getId() )"
msgstr "<literal>foo.getId().equals( bar.getId() )"

#. Tag: term
#, no-c-format
msgid "JVM Identity"
msgstr "JVM 識別子"

#. Tag: para
#, no-c-format
msgid "<literal>foo==bar"
msgstr ""

#. Tag: para
#, no-c-format
msgid ""
"For objects attached to a <emphasis>particular SessionSession), the two "
"notions are equivalent and JVM identity for database identity is guaranteed "
"by Hibernate. While the application might concurrently access the \"same"
"\" (persistent identity) business object in two different sessions, the two "
"instances will actually be \"different\" (JVM identity). Conflicts are "
"resolved using an optimistic approach and automatic versioning at flush/"
"commit time."
msgstr ""
"<emphasis>特定のSession に追加されたオブジェク"
"トにとって （すなわち、１つの <literal>Session のスコープの中で"
"は） 、２つの概念は同じです。データベース同一性と JVM 同一性が一致すること"
"を、 Hibernate が保証します。しかし、アプリケーションが２つの異なるセッション"
"から「同じ」（永続性識別子の）ビジネスオブジェクトに同時にアクセスする限り、"
"２つのインスタンスは実際に（ JVM 識別子が）「異なり」ます。楽観的アプローチに"
"よって、 （自動バージョニングの） フラッシュ／コミット時にコンフリクトが解決"
"されます。"

#. Tag: para
#, no-c-format
msgid ""
"This approach leaves Hibernate and the database to worry about concurrency. "
"It also provides the best scalability, since guaranteeing identity in single-"
"threaded units of work means that it does not need expensive locking or "
"other means of synchronization. The application does not need to synchronize "
"on any business object, as long as it maintains a single thread per "
"<literal>Session. Within a Session the "
"application can safely use <literal>== to compare objects."
msgstr ""
"このアプローチでは、 Hibernate とデータベースに同時実行についての心配が残りま"
"す。一方で、最高のスケーラビリティが提供されます。なぜなら、１スレッドの作業"
"単位の中で一意性が保証されれば、高価なロックや同期化が不要になるためです。 "
"<literal>Session ごとに１つのスレッドを貼り付ける限り、アプリケー"
"ションはビジネスオブジェクトを synchronize する必要はありません。 "
"<literal>Session 内では、アプリケーションはオブジェクトを比較するた"
"めに、 <literal>== を安全に使用できます。"

#. Tag: para
#, no-c-format
msgid ""
"However, an application that uses <literal>== outside of a "
"<literal>Session might produce unexpected results. This might "
"occur even in some unexpected places. For example, if you put two detached "
"instances into the same <literal>Set, both might have the same "
"database identity (i.e., they represent the same row). JVM identity, "
"however, is by definition not guaranteed for instances in a detached state. "
"The developer has to override the <literal>equals() and "
"<literal>hashCode() methods in persistent classes and implement "
"their own notion of object equality. There is one caveat: never use the "
"database identifier to implement equality. Use a business key that is a "
"combination of unique, usually immutable, attributes. The database "
"identifier will change if a transient object is made persistent. If the "
"transient instance (usually together with detached instances) is held in a "
"<literal>Set, changing the hashcode breaks the contract of the "
"<literal>Set. Attributes for business keys do not have to be as "
"stable as database primary keys; you only have to guarantee stability as "
"long as the objects are in the same <literal>Set. See the "
"Hibernate website for a more thorough discussion of this issue. Please note "
"that this is not a Hibernate issue, but simply how Java object identity and "
"equality has to be implemented."
msgstr ""
"けれども、 <literal>Session の外で == を使うアプ"
"リケーションは、予期しない結果に遭遇します。これは予期しない場所で起こりえま"
"す。例えば、２つの分離インスタンスを同じ <literal>Set に put したと"
"きなどです。両方とも同じデータベース識別子を持ちます（すなわち、同じ行を表し"
"ます）。しかし、分離状態のインスタンスの JVM 識別子は当然保証されません。開発"
"者は、永続性クラスの <literal>equals() と hashCode() "
"に保持する場合、ハッシュコードが変わるということは、 <literal>Set "
"の契約を破るということです。ビジネスキーのための属性は、データベースの主キー"
"ほど安定すべきではないです。オブジェクトが同じ <literal>Set の中に"
"いる間だけ、安定を保証すべきです。この問題のより徹底的な議論は、 Hibernate "
"の Web サイトを参照してください。また、これは Hibernate の問題ではなく、単に "
"Java オブジェクトの識別子や等価性をどのように実装すべきかということです。"

#. Tag: title
#, no-c-format
msgid "Common issues"
msgstr "一般的な問題"

#. Tag: para
#, no-c-format
msgid ""
"Do not use the anti-patterns <emphasis>session-per-user-session "
"or <emphasis>session-per-application (there are, however, rare "
"exceptions to this rule). Some of the following issues might also arise "
"within the recommended patterns, so ensure that you understand the "
"implications before making a design decision:"
msgstr ""
"<emphasis>session-per-user-session と session-per-"
"application</emphasis> アンチパターンは使ってはいけません（もちろん、まれに例"
"外があります）。注記：下記の問題のいくつかは、推奨されるパターンとしても出現"
"します。設計を決定する前に、裏の意味を理解するようにしてください。"

#. Tag: para
#, no-c-format
msgid ""
"A <literal>Session is not thread-safe. Things that work "
"concurrently, like HTTP requests, session beans, or Swing workers, will "
"cause race conditions if a <literal>Session instance is shared. If "
"you keep your Hibernate <literal>Session in your "
"<literal>HttpSession (this is discussed later in the chapter), you "
"should consider synchronizing access to your Http session. Otherwise, a user "
"that clicks reload fast enough can use the same <literal>Session "
"in two concurrently running threads."
msgstr ""
"<literal>Session はスレッドセーフではありません。 HTTP リクエスト、"
"セッション Bean 、 Swing ワーカーのように、同時実行が可能なものが "
"<literal>Session インスタンスを共有すると、競合状態を引き起こしま"
"す。（後で議論する） <literal>HttpSession の中で Hibernate "
"<literal>Session を保持する場合、 HttpSession へのアクセスを同期化"
"することを考慮すべきです。さもなければ、ユーザーが十分早くリロードをクリック"
"すると、同時に走る２つのスレッドの中で、同じ <literal>Session が使"
"われます。"

#. Tag: para
#, no-c-format
msgid ""
"An exception thrown by Hibernate means you have to rollback your database "
"transaction and close the <literal>Session immediately (this is "
"discussed in more detail later in the chapter). If your <literal>Session を閉じるべきです （詳細を後で議論しま"
"す） 。 <literal>Session がアプリケーションに結び付けられているので"
"あれば、アプリケーションを停止すべきです。データベーストランザクションをロー"
"ルバックしても、ビジネスオブジェクトはトランザクションを開始したときの状態に"
"戻りません。これは、データベースの状態とビジネスオブジェクトは同期していない"
"ことを意味します。通常これは問題になりません。なぜなら、例外は回復できないか"
"らです。とにかくロールバックした後にやり直すべきです。"

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"The <literal>Session caches every object that is in a persistent "
"state (watched and checked for dirty state by Hibernate). If you keep it "
"open for a long time or simply load too much data, it will grow endlessly "
"until you get an OutOfMemoryException. One solution is to call <literal>clear"
"()</literal> and evict() to manage the Session open for the duration of a user session "
"also means a higher probability of stale data."
msgstr ""
"<literal>Session は永続 （persistent） 状態のすべてのオブジェクトを"
"キャッシュします（ Hibernate は監視し、ダーティ状態かチェックします）。これ"
"は、長い間セッションを開いたままにするか、非常に多くのデータをロードし続ける"
"かした場合は、 OutOfMemoryException が発生するまで無限に大きくなることを意味"
"します。解決策の１つは、<literal>Session キャッシュを管理するため"
"に、 <literal>clear() か evict() を呼ぶことで"
"す。しかし、大きなデータを処理する必要があるなら、たぶんストアドプロシージャ"
"を考慮するべきでしょう。いくつかの解決策は、 <xref linkend=\"batch\"/> で紹介"
"されています。ユーザーセッションの間、 <literal>Session を開いたま"
"まにするということは、データが新鮮でなくなる確率が高くなることを意味します。"

#. Tag: title
#, no-c-format
msgid "Database transaction demarcation"
msgstr "データベーストランザクション境界"

#. Tag: para
#, 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
#, 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 (begin, commit, or rollback database transactions) themselves. 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 ""
"J2EE 環境に管理されていない状態 （すなわち、スタンドアロン、単純な Web や "
"Swing アプリケーション）でも、管理された状態でも、 Hibernate アプリケーション"
"を実行できます。管理されていない環境では、 Hiberante がデータベースのコネク"
"ションプールを提供します。アプリケーション開発者は、トランザクション境界を手"
"動で設定しなければなりません。言い換えると、データベーストランザクションの開"
"始、コミット、ロールバックを開発者自身が設定する必要があるということです。通"
"常、管理された環境では、コンテナ管理によるトランザクション （CMT） が提供され"
"ます。例えば、セッション Bean のデプロイメントディスクリプタで宣言的に定義"
"し、トランザクションを組み立てます。プログラムによるトランザクション境界はも"
"う必要ありません。"

#. Tag: para
#, 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 use programmatic "
"transaction demarcation. Hibernate offers a wrapper API called "
"<literal>Transaction 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 ""
"しかしながら、管理されていないリソースローカルな環境と JTA に依存したシステ"
"ム （CMT ではなく BMT） の両方に、永続化層をポータブルに保つのは、しばしば望"
"ましいことです。デプロイ環境のネイティブのトランザクションシステムを呼び出す "
"<literal>Transaction というラッパー API を Hibernate が提供します。"
"この API を使うかは任意ですが、 CMT のセッション Bean を使わないのであれば、"
"使うことを強く推奨します。"

#. Tag: para
#, no-c-format
msgid ""
"Ending a <literal>Session usually involves four distinct phases:"
msgstr ""
"通常、 <literal>Session 終了は、４つの異なるフェーズを含みます:"

#. Tag: para
#, no-c-format
msgid "flush the session"
msgstr "セッションのフラッシュ"

#. Tag: para
#, no-c-format
msgid "commit the transaction"
msgstr "トランザクションのコミット"

#. Tag: para
#, no-c-format
msgid "close the session"
msgstr "セッションのクローズ"

#. Tag: para
#, no-c-format
msgid "handle exceptions"
msgstr "例外のハンドリング"

#. Tag: para
#, no-c-format
msgid ""
"We discussed Flushing the session earlier, so we will now have a closer look "
"at transaction demarcation and exception handling in both managed and non-"
"managed environments."
msgstr ""
"セッションのフラッシュについては、前の方で既に議論しました。管理された環境と"
"管理されていない環境の両方について、トランザクション境界と例外ハンドリングを"
"もっと詳しく見ていきましょう。"

#. Tag: title
#, no-c-format
msgid "Non-managed environment"
msgstr "管理されていない環境"

#. Tag: para
#, 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 ""
"Hibernate 永続化層を管理されていない環境で実装する場合は、通常単純なコネク"
"ションプール （すなわち DataSource ではない） によって、データベースコネク"
"ションを制御します。 Hibernate はそのコネクションプールから必要なコネクション"
"を取得します。セッション／トランザクション制御のイディオムは次のようになりま"
"す："

#. Tag: para
#, fuzzy, no-c-format
msgid ""
"You do not have to <literal>flush() the Session "
"explicitly: the call to <literal>commit() automatically triggers "
"the synchronization depending on the <link linkend=\"objectstate-flushing"
"\">FlushMode</link> for the session. A call to close() "
"marks the end of a session. The main implication of <literal>close() の flush() を呼び出す"
"べきではなく、 <literal>commit() を呼び出すことにより、自動的に同期"
"化処理が実行されます （セッションの <xref linkend=\"objectstate-flushing\"/> "
"FlushMode に依存している）。 <literal>close() を呼び出すことによ"
"り、セッションの終わりを明確にします。 <literal>close() が暗黙的に"
"行う主なことは、セッションが JDBC コネクションを開放することです。上記の "
"Java コードはポータブルであり、管理されていない環境と JTA 環境の両方で実行で"
"きます。"

#. Tag: para
#, no-c-format
msgid ""
"As outlined earlier, a much more flexible solution is Hibernate's built-in "
"\"current session\" context management:"
msgstr ""
"より適応性のある解決策は、 Hibernate に予め組み込まれている \"current session"
"\" コンテキスト管理です。言葉で説明するより下記を見たほうが速いでしょう。"

#. Tag: para
#, no-c-format
msgid ""
"You will not 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 (and usually can only "
"clean up and exit), are in different layers. The current context management "
"by Hibernate can significantly simplify this design by accessing a "
"<literal>SessionFactory. Exception handling is discussed later in "
"this chapter."
msgstr ""
"正規のアプリケーションの中では、このようなコードの切れ端を決して見ないでしょ"
"う。致命的な （システム） 例外は、常に「最上位」でキャッチすべきです。言い換"
"えれば、 （永続化層で） Hibernate 呼び出しを実行するコードと、 "
"<literal>RuntimeException を制御する （通常はクリーンアップと終了の"
"み行うことができる） コードは、別々の層の中にあります。 Hibernate によるカレ"
"ントコンテキスト管理は、この設計をかなり単純にします。必要なのは、 "
"<literal>SessionFactory にアクセスすることだけです。例外処理は、こ"
"の章の後のほうで議論します。"

#. Tag: para
#, no-c-format
msgid ""
"You should select <literal>org.hibernate.transaction.JDBCTransactionFactory"
"\"thread\"</literal> as your hibernate."
"current_session_context_class</literal>."
msgstr ""
"注記：（デフォルトですが） <literal>org.hibernate.transaction."
"JDBCTransactionFactory</literal> を選択するべきです。第2の用例としては、 "
"<literal>hibernate.current_session_context_class を "
"\"thread\"</literal> とするとよいでしょう。"

#. Tag: title
#, no-c-format
msgid "Using JTA"
msgstr "JTA を使用する"

#. Tag: para
#, no-c-format
msgid ""
"If your persistence layer runs in an application server (for example, 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 ""
"永続化層をアプリケーションサーバー （例えば、 EJB セッション Bean の背後） で"
"実行する場合、 Hibernate から取得するすべてのデータソースコネクションは、自動"
"的にグローバル JTA トランザクションの一部になります。 EJB を使わずに、スタン"
"ドアロンの JTA 実装を導入することもできます。 JTA 統合のために、 Hibernate は"
"２つの戦略を提供します。"

#. Tag: para
#, 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 API. The transaction management code is "
"identical to the non-managed environment."
msgstr ""
"Bean 管理トランザクション（BMT）を使い、 <literal>Transaction API "
"を使う場合、 Hibernate はアプリケーションサーバーに BMT トランザクションの開"
"始と終わりを告げます。すなわち、トランザクション管理のコードは、管理されない"
"環境と同じになります。"

#. Tag: para
#, no-c-format
msgid ""
"If you want to use a transaction-bound <literal>Session, that is, "
"the <literal>getCurrentSession() functionality for easy context "
"propagation, use the JTA <literal>UserTransaction API directly:"
msgstr ""
"トランザクション境界として <literal>Session を使いたい場合、簡単に"
"コンテキストを伝播する機能である <literal>getCurrentSession() があ"
"るので、 JTAの <literal>UserTransaction API を直接使用すべきでしょ"
"う。"

#. Tag: para
#, no-c-format
msgid ""
"With CMT, transaction demarcation is completed in session bean deployment "
"descriptors, not programmatically. The code is reduced to:"
msgstr ""
"CMT では、トランザクション境界をセッション Bean のデプロイメントディスクリプ"
"タで定義し、プログラムでは行いません。ゆえに、コードは次のように少なくなりま"
"す:"

#. Tag: para
#, no-c-format
msgid ""
"In a CMT/EJB, even rollback happens automatically. An unhandled "
"<literal>RuntimeException thrown by a session bean method tells "
"the container to set the global transaction to rollback. <emphasis>You do "
"not need to use the Hibernate <literal>Transaction API at all with "
"BMT or CMT, and you get automatic propagation of the \"current\" Session "
"bound to the transaction.</emphasis>"
msgstr ""
"CMT/EJB の中では、常にロールバックが自動的に実施されます。なぜなら、セッショ"
"ン Bean のメソッドにより投げられた制御されていない "
"<literal>RuntimeException は、グローバルトランザクションをロール"
"バックするようにコンテナに伝えるためです。 <emphasis>これは、 BMT もしくは "
"CMT と一緒に Hibernate <literal>Transaction API を使う必要はまった"
"くないということを意味し、トランザクションにバインドする「現在の」セッション"
"を自動伝搬できます。</emphasis>"

#. Tag: para
#, no-c-format
msgid ""
"When configuring Hibernate's transaction factory, 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. Remember to also set "
"<literal>hibernate.transaction.manager_lookup_class. Ensure that "
"your <literal>hibernate.current_session_context_class is either "
"unset (backwards compatibility), or is set to <literal>\"jta\"."
msgstr ""
"Hibernate のトランザクションファクトリを設定する際に、 JTA を直接使う （BMT"
"の） 場合は <literal>org.hibernate.transaction.JTATransactionFactoryorg.hibernate."
"transaction.CMTTransactionFactory</literal> を選択すべきだということに注意し"
"てください。 <literal>hibernate.transaction.manager_lookup_class を"
"セットすることも思い出してください。なお、 <literal>hibernate."
"current_session_context_class</literal> は、セットしないか（後方互換）、 "
"<literal>\"jta\" をセットしてください。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>getCurrentSession() operation has one downside in a "
"JTA environment. There is one caveat to the use of <literal>after_statement or "
"<literal>Iterator instances returned by scroll()iterate(). You must "
"release the underlying database cursor by calling <literal>ScrollableResults."
"close()</literal> or Hibernate.close(Iterator) explicitly "
"from a <literal>finally block. Most applications can easily avoid "
"using <literal>scroll() or iterate() from the "
"JTA or CMT code.)"
msgstr ""
"<literal>getCurrentSession() オペレーションは、 JTA 環境では１つの"
"欠点を持ちます。デフォルトで使われる <literal>after_statement コネ"
"クションリリースモードを使用する上で、警告が１つあります。 JTA 仕様の愚かな制"
"約のために、 <literal>scroll() または iterate() "
"が返した、閉じられていない <literal>ScrollableResults または "
"<literal>Iterator インスタンスを Hibernate が自動的にクリーンアップ"
"することはできません。 <literal>finally ブロックの中で、 "
"<literal>ScrollableResults.close() または Hibernate.close"
"(Iterator)</literal> を明示的に呼び出して、裏に潜んだデータベースカーソルを解"
"放 <emphasis>しなければなりません。 （もちろん、多くのアプリケー"
"ションでは、 JTA か CMT コードで <literal>scroll() や "
"<literal>iterate() の使用を避けるのは容易です。）"

#. Tag: title
#, no-c-format
msgid "Exception handling"
msgstr "例外ハンドリング"

#. Tag: para
#, no-c-format
msgid ""
"If the <literal>Session throws an exception, including any "
"<literal>SQLException, immediately rollback the database "
"transaction, call <literal>Session.close() and discard the "
"<literal>Session instance. Certain methods of Sessionnot leave the session in a consistent "
"state. No exception thrown by Hibernate can be treated as recoverable. "
"Ensure that the <literal>Session will be closed by calling "
"<literal>close() in a finally block."
msgstr ""
"<literal>Session が例外 （SQLExceptionを含む） "
"を投げた場合、直ちに、データベーストランザクションをロールバックし、 "
"<literal>Session.close() を呼び、 Session インス"
"タンスを破棄すべきです。 <literal>Session のいくつかのメソッドは、"
"セッションの状態を <emphasis>矛盾したまま にします。 Hibernate が"
"投げた例外を、回復できるものとして扱うことはできません。 <literal>finallyclose() を呼んで、 "
"<literal>Session を確実に閉じてください。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>HibernateException, which wraps most of the errors "
"that can occur in a Hibernate persistence layer, is an unchecked exception. "
"It was not in older versions of Hibernate. In our opinion, we should not "
"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 "
"either 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 that are not a <literal>HibernateException. "
"These are not recoverable and appropriate action should be taken."
msgstr ""
"<literal>HibernateException は、 Hibernate 永続化層の中で発生する多"
"くのエラーをラップする、検査されない例外です （ Hibernate の古いバージョンは"
"違いました） 。私たちの意見は、アプリケーション開発者に回復不可能な例外を下層"
"でキャッチすることを強要すべきではないということです。多くのシステムでは、検"
"査されない例外と致命的な例外は、コールスタックの最初のフレームの１つ （例え"
"ば、最上位の層で） でハンドリングし、エラーメッセージをアプリケーションユー"
"ザーに表示します （もしくは、他の適切な処理を実施します） 。 Hibernate は、"
"<literal>HibernateException 以外の検査されない例外も投げることに注"
"意してください。これらもまた、回復不可能であり、適切な処理を実施すべきです。"

#. Tag: para
#, no-c-format
msgid ""
"Hibernate wraps <literal>SQLExceptions thrown while interacting "
"with the database in a <literal>JDBCException. In fact, Hibernate "
"will attempt to convert the exception into a more meaningful subclass of "
"<literal>JDBCException. The underlying SQLExceptionJDBCException.getCause()SQLException into an "
"appropriate <literal>JDBCException subclass using the "
"<literal>SQLExceptionConverter attached to the "
"<literal>SessionFactory. By default, the "
"<literal>SQLExceptionConverter is defined by the configured "
"dialect. However, it is also possible to plug in a custom implementation. "
"See the javadocs for the <literal>SQLExceptionConverterFactory "
"class for details. The standard <literal>JDBCException subtypes "
"are:"
msgstr ""
"Hibernate は、データベースとの対話中に投げられた <literal>SQLExceptionJDBCException でラップします。実は、例外をより"
"意味のある <literal>JDBCException のサブクラスに変換しようと試みま"
"す。元の <literal>SQLException は、 JDBCException.getCause"
"()</literal> によりいつでも得られます。 Hibernate は、 "
"<literal>SessionFactory に追加されている "
"<literal>SQLExceptionConverter を使い、 SQLExceptionJDBCException サブクラスに変換します。デ"
"フォルトでは、 <literal>SQLExceptionConverter は設定されている SQL "
"方言により定義されます。一方で、独自の実装に差し替えることもできます （詳細"
"は、 <literal>SQLExceptionConverterFactory クラスの Javadoc を参照"
"してください）。標準的な <literal>JDBCException のサブタイプを下記"
"に示します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>JDBCConnectionException: indicates an error with the "
"underlying JDBC communication."
msgstr ""
"<literal>JDBCConnectionException - 基礎となる JDBC 通信のエラーを表"
"します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>SQLGrammarException: indicates a grammar or syntax "
"problem with the issued SQL."
msgstr ""
"<literal>SQLGrammarException - 発行する SQL の文法もしくは構文の問"
"題を表します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>ConstraintViolationException: indicates some form of "
"integrity constraint violation."
msgstr ""
"<literal>ConstraintViolationException - 何らかの形式の完全性制約違"
"反を表します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockAcquisitionException: indicates an error acquiring a "
"lock level necessary to perform the requested operation."
msgstr ""
"<literal>LockAcquisitionException - 要求された操作を実施するのに必"
"要なロックレベルを得る際のエラーを表します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>GenericJDBCException: a generic exception which did not "
"fall into any of the other categories."
msgstr ""
"<literal>GenericJDBCException - 他のカテゴリに一致しなかった一般的"
"な例外です。"

#. Tag: title
#, no-c-format
msgid "Transaction timeout"
msgstr "トランザクションのタイムアウト"

#. Tag: para
#, no-c-format
msgid ""
"An 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 object."
msgstr ""
"EJB のような管理された環境が提供するきわめて重要な特徴の１つは、トランザク"
"ションのタイムアウトです。これは管理されていないコードには提供できません。ト"
"ランザクションタイムアウトは、不品行なトランザクションがユーザーにレスポンス"
"を返さないまま、無期限にリソースを使い続けないことを保障します。管理された環"
"境 （JTA） の外では、 Hibernate はこの機能をフルに提供できません。しかしなが"
"ら、 Hibernate は次のようなデータアクセス操作の制御くらいはできます。データ"
"ベースレベルのデッドロックや大きなリザルトセットを返すクエリを定義されたタイ"
"ムアウトによって確実に制限します。管理された環境では、 Hibernate はトランザク"
"ションタイムアウトを JTA に委譲します。この機能は、 Hibernate の "
"<literal>Transaction オブジェクトによって抽象化されています。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>setTimeout() cannot be called in a CMT bean, where "
"transaction timeouts must be defined declaratively."
msgstr ""
"CMT Bean の中では <literal>setTimeout() を呼び出せないことに注意し"
"てください。トランザクションタイムアウトは宣言的に定義されるべきです。"

#. Tag: title
#, no-c-format
msgid "Optimistic concurrency control"
msgstr "楽観的同時実行制御"

#. Tag: para
#, 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 three possible approaches to "
"writing application code that uses optimistic concurrency. The use cases we "
"discuss are in the context of long conversations, but version checking also "
"has the benefit of preventing lost updates in single database transactions."
msgstr ""
"高い並列性と高いスケーラビリティの両方を実現するアプローチは、バージョニング"
"を使った楽観的同時実行制御のみです。更新の衝突を見つけるために（および、更新"
"が失われるのを防ぐために）、バージョン番号もしくはタイムスタンプを使って、"
"バージョンをチェックします。 Hibernate は、楽観的同時実行を行うアプリケーショ"
"ンコードを書くためのアプローチを３つ提供します。私たちが見せるユースケース"
"は、長い対話を持ちますが、バージョンチェックはまだ１つのデータベーストランザ"
"クションの中で更新を失うことを防ぐ利点も持っています。"

#. Tag: title
#, no-c-format
msgid "Application version checking"
msgstr "アプリケーションによるバージョンチェック"

#. Tag: para
#, no-c-format
msgid ""
"In an implementation without much help from Hibernate, each interaction with "
"the database occurs in a new <literal>Session and the developer is "
"responsible for reloading all persistent instances from the database before "
"manipulating them. The application is forced 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 ""
"Hibernate にほとんど助けてもらわずに実装するケースです。データベースとのやり"
"取りは、それぞれ新しい <literal>Session の中で起こります。開発者"
"は、すべての永続性インスタンスを操作する前に、データベースから再読み込みする"
"責務があります。このアプローチでは、対話トランザクションの分離を守るために、"
"アプリケーション自身がバージョンチェックを行う必要があります。このアプローチ"
"は、データベースアクセスの中では、最も非効率です。エンティティ EJB と最も似て"
"いるアプローチです。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>version property is mapped using <"
"version></literal>, and Hibernate will automatically increment it during "
"flush if the entity is dirty."
msgstr ""
"<literal><version> を使って、 version プロ"
"パティをマッピングします。 Hibernate は、エンティティがダーティである場合、フ"
"ラッシュし、その間に <literal>version プロパティを自動的にインクリ"
"メントします。"

#. Tag: para
#, no-c-format
msgid ""
"If you are operating in a low-data-concurrency environment, and do not "
"require version checking, you can use this approach and skip the version "
"check. In this case, <emphasis>last commit wins is the default "
"strategy for long conversations. Be aware 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 ""
"もちろん、データの並列性が低い環境で運用しており、バージョンチェックが不要な"
"ら、このアプローチを使い、バージョンチェックをスキップするだけです。その場合"
"は、長い対話には、 <emphasis>最後にコミットしたものが勝つ がデフォ"
"ルトの戦略でしょう。このアプローチは、アプリケーションのユーザーを混乱させる"
"かもしれないことを心に留めて置いてください。それは、エラーメッセージや競合し"
"た変更をマージする機会がないまま、更新を失う可能性があるからです。"

#. Tag: para
#, no-c-format
msgid ""
"Manual version checking is only feasible in 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 instance and its persistent instances "
"that are used for the whole conversation are known as <emphasis>session-per-"
"conversation</emphasis>. Hibernate checks instance versions at flush time, "
"throwing an exception if concurrent modification is detected. It is 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 ""
"１つの <literal>Session インスタンスとその永続性インスタンスは、 "
"<emphasis>session-per-conversation として知られる、対話全体で使わ"
"れます。 Hibernate はフラッシュする際に、インスタンスのバージョンをチェックし"
"ます。同時に修正されたことを検出すると、例外を投げます。この例外をキャッチし"
"て扱うのは、開発者の責任です （一般的な選択肢は、変更をマージするか古くない"
"データでビジネス対話を再スタートする機会をユーザーに提供することです）。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>Session 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 does not version "
"check or reattach detached instances, nor does it have to reload instances "
"in every database transaction."
msgstr ""
"ユーザーの対話を待っているときは、 <literal>Session を基礎となる "
"JDBC コネクションから切り離します。このアプローチは、データベースアクセスの中"
"では、最も効率的です。アプリケーションは、バージョンチェックや分離されたイン"
"スタンスを再追加することに関心を持つ必要はありません。また、あらゆるデータ"
"ベーストランザクションの中でインスタンスを再読み込みする必要はありません。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>foo object knows which Session 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 are not updating, you can call <literal>Session.lock() with "
"<literal>LockMode.READ on any objects that might have been updated "
"by another transaction. You do not need to lock any data that you "
"<emphasis>are updating. Usually you would set FlushMode."
"MANUAL</literal> on an extended Session, so that only the "
"last database transaction cycle is allowed to actually persist all "
"modifications made in this conversation. Only this last database transaction "
"will include the <literal>flush() operation, and then "
"<literal>close() the session to end the conversation."
msgstr ""
"<literal>foo オブジェクトは、自分をロードした SessionSession.lock() を呼び出すことができま"
"す。更新して <emphasis>いる データをロックする必要はありません。通"
"常、拡張 <literal>Session に FlushMode.MANUAL を"
"セットします。最後のデータベーストランザクションの周期でのみ、対話の中で変更"
"されたすべてを実際に永続化させるためです。ゆえに、最後のデータベーストランザ"
"クションのみ <literal>flush() オペレーションを含みます。そして、対"
"話を終わらせるために、セッションも <literal>close() します。"

#. Tag: para
#, no-c-format
msgid ""
"This pattern is problematic if the <literal>Session is too big to "
"be stored during user think time (for example, an <literal>HttpSessionSession only for a single conversation as it will soon "
"have stale data."
msgstr ""
"ユーザーが考慮中に、格納することができないくらい <literal>Session "
"が大きいのであれば、このパターンは問題があります。例えば、 "
"<literal>HttpSession は可能な限り小さく保つべきです。 "
"<literal>Session は （強制的に） １次キャッシュでもあり、ロードした"
"オブジェクトをすべて保持します。おそらく、リクエスト／レスポンスのサイクルが"
"数回であれば、この戦略が使えます。１つの対話のためだけに <literal>Session. These methods are deprecated, "
"as beginning and ending a transaction has the same effect."
msgstr ""
"Hibernate の以前のバージョンは、明示的な <literal>Session の切断と"
"再接続が必要だったことに注意してください。これらのメソッドは非推奨になりまし"
"た。なぜなら、トランザクションの開始と終了は同じ効果があるためです。"

#. Tag: para
#, no-c-format
msgid ""
"Keep the disconnected <literal>Session close to the persistence "
"layer. Use an EJB stateful session bean to hold the <literal>Session."
msgstr ""
"切断した <literal>Session を永続化層の近くで保持すべきであることに"
"注意してください。言い換えると、３層環境の中で <literal>Session を"
"保持するために、 EJB ステートフルセッション Bean を使ってください。 "
"<literal>HttpSession に格納するために、 Web 層に転送しないでくださ"
"い （別の層へのシリアライズもしないでください）。"

#. Tag: para
#, no-c-format
msgid ""
"The extended session pattern, or <emphasis>session-per-conversation for this. See the Hibernate Wiki "
"for examples."
msgstr ""
"拡張セッションパターン （もしくは、 <emphasis>session-per-conversation の実装を供"
"給する必要があります。 Hibernate Wiki にある例を参照してください。"

#. Tag: title
#, no-c-format
msgid "Detached objects and automatic versioning"
msgstr "デタッチされたオブジェクトと自動バージョニング"

#. Tag: para
#, no-c-format
msgid ""
"Each interaction with the persistent store occurs in a new <literal>Session "
"and then reattaches them using <literal>Session.update(), "
"<literal>Session.saveOrUpdate(), or Session.merge() により、永続化ストア （訳注：ＤＢ） との対"
"話が発生します。また一方、同じ永続性インスタンスが、データベースとの対話ごと"
"に再利用されます。アプリケーションは、元々は他の <literal>Session "
"でロードされ、デタッチされたインスタンスの状態を操作します。そして、 "
"<literal>Session.update() もしくは、 Session.saveOrUpdate"
"()</literal> 、 Session.merge() を使って、それらのインスタ"
"ンスを再追加します。"

#. Tag: para
#, no-c-format
msgid ""
"Again, Hibernate will check instance versions during flush, throwing an "
"exception if conflicting updates occurred."
msgstr ""
"この場合もやはり、 Hibernate はフラッシュする際に、インスタンスのバージョンを"
"チェックします。更新の競合が発生した場合には、例外を投げます。"

#. Tag: para
#, no-c-format
msgid ""
"You can also call <literal>lock() instead of update()LockMode.READ (performing a version "
"check and bypassing all caches) if you are sure that the object has not been "
"modified."
msgstr ""
"オブジェクトが修正されていないことを確信している場合は、 <literal>update()LockMode.READ を使って、 "
"<literal>lock() を呼び出すこともできます （すべてのキャッシュを迂回"
"し、バージョンチェックを実施します）。"

#. Tag: title
#, no-c-format
msgid "Customizing automatic versioning"
msgstr "自動バージョニングのカスタマイズ"

#. Tag: para
#, no-c-format
msgid ""
"You can disable Hibernate's automatic version increment for particular "
"properties and collections by setting the <literal>optimistic-lock "
"mapping attribute to <literal>false. Hibernate will then no longer "
"increment versions if the property is dirty."
msgstr ""
"マッピングの <literal>optimistic-lock 属性に false in the "
"<literal><class> mapping. This conceptually only works if "
"Hibernate can compare the old and the new state (i.e., if you use a single "
"long <literal>Session and not session-per-request-with-detached-"
"objects)."
msgstr ""
"レガシーのデータベーススキーマは、しばしば固定的であり、変更できません。また"
"は、他のアプリケーションが同じデータベースにアクセスしなければならず、そのア"
"プリケーションはバージョン番号やタイムスタンプさえ操作する方法を知りません。"
"どちらの場合も、テーブルの特定のカラムを当てにして、バージョニングを行えませ"
"ん。バージョンやタイムスタンプのプロパティをマッピングせずに、バージョン"
"チェックさせるために、 <literal><class> マッピングに "
"<literal>optimistic-lock=\"all\" を指定してください。行のすべての"
"フィールドの状態を比較するようになります。これは、 Hibernate が古い状態と新し"
"い状態を比較できる場合に、理論的に動作するだけであることに注意してください。"
"例えば、 session-per-request-with-detached-objects ではなく、１つの長い "
"<literal>Session を使う場合です。"

#. Tag: para
#, no-c-format
msgid ""
"Concurrent modification can be permitted in instances where the changes that "
"have been made do not overlap. If you set <literal>optimistic-lock=\"dirty"
"\"</literal> when mapping the <class>, Hibernate "
"will only compare dirty fields during flush."
msgstr ""
"ときどき、行われた変更が重ならない限り、同時に行われた変更を受け入れることが"
"できます。 <literal><class> マッピングに optimistic-"
"lock=\"dirty\"</literal> を設定した場合、フラッシュする際に、 Hibernate は"
"ダーティフィールドのみを比較します。"

#. Tag: para
#, no-c-format
msgid ""
"In both cases, with dedicated version/timestamp columns or with a full/dirty "
"field comparison, Hibernate uses a single <literal>UPDATE "
"statement, with an appropriate <literal>WHERE clause, per entity "
"to execute the version check and update the information. If you use "
"transitive persistence to cascade reattachment to associated entities, "
"Hibernate may execute unnecessary updates. This is usually not a problem, "
"but <emphasis>on update 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\"<class> mapping, forcing Hibernate "
"to <literal>SELECT the instance to ensure that changes did occur "
"before updating the row."
msgstr ""
"専用のバージョン／タイムスタンプのカラムを使う場合、もしくはすべて／ダーティ"
"のフィールドを比較する場合どちらであっても、 Hibernate はエンティティごとに1"
"つの <literal>UPDATE 文を （適切な WHERE 節と共"
"に） 使い、バージョンチェックと情報の更新を行います。関連するエンティティの再"
"追加をカスケードするために、連鎖的な永続化を使用した場合、不必要な更新を実行"
"するかもしれません。これは通常問題になりません。しかし、分離したインスタンス"
"を変更していなくとも、データベースの <emphasis>on update トリガー"
"が実行されるかもしれません。 <literal><class> マッピングに "
"<literal>select-before-update=\"true\" を設定することによって、この"
"振る舞いをカスタマイズできます。確実に変更されたかを確認するために、行を更新"
"する前に、必ずインスタンスを <literal>SELECT します。"

#. Tag: title
#, no-c-format
msgid "Pessimistic locking"
msgstr "悲観的ロック"

#. Tag: para
#, no-c-format
msgid ""
"It is not intended that users spend much time worrying about locking "
"strategies. It is 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 wish to obtain exclusive pessimistic locks or re-obtain "
"locks at the start of a new transaction."
msgstr ""
"ユーザーがロック戦略に悩むのに多くの時間を費やすことを意図していません。通常"
"は、 JDBC コネクションに分離レベルを指定し、単にデータベースにすべての仕事を"
"させれば十分です。しかしながら、高度なユーザーは、排他的な悲観的ロックを獲得"
"することか、新しいトランザクションが開始される際にロックを再獲得することをと"
"きどき望むかもしれません。"

#. Tag: para
#, no-c-format
msgid ""
"Hibernate will always use the locking mechanism of the database; it never "
"lock objects in memory."
msgstr ""
"Hibernate はいつもデータベースのロックの仕組みを使います。メモリ内のオブジェ"
"クトを決してロックしません。"

#. Tag: para
#, no-c-format
msgid ""
"The <literal>LockMode class defines the different lock levels that "
"can be acquired by Hibernate. A lock is obtained by the following mechanisms:"
msgstr ""
"<literal>LockMode クラスは、 Hibernate が獲得できる異なるロックレベ"
"ルを定義します。以下の仕組みにより、ロックを獲得できます。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.WRITE is acquired automatically when Hibernate "
"updates or inserts a row."
msgstr ""
"<literal>LockMode.WRITE は、 Hibernate が行を更新もしくは挿入する際"
"に自動的に得られます。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.UPGRADE can be acquired upon explicit user "
"request using <literal>SELECT ... FOR UPDATE on databases which "
"support that syntax."
msgstr ""
"<literal>LockMode.UPGRADE は、データベースでサポートされている文法 "
"<literal>SELECT ... FOR UPDATE を使った、明示的なユーザー要求により"
"得られるかもしれません。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.UPGRADE_NOWAIT can be acquired upon explicit "
"user request using a <literal>SELECT ... FOR UPDATE NOWAIT under "
"Oracle."
msgstr ""
"<literal>LockMode.UPGRADE_NOWAIT は、 Oracle で "
"<literal>SELECT ... FOR UPDATE NOWAIT を使った、明示的なユーザー要"
"求により得られるかもしれません。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.READ is acquired automatically when Hibernate "
"reads data under Repeatable Read or Serializable isolation level. It can be "
"re-acquired by explicit user request."
msgstr ""
"<literal>LockMode.READ は、 Repeatable Read もしくは Serializable "
"の分離レベルで、データを読んだ際に自動的に得られます。おそらく、明示的なユー"
"ザー要求により、再取得されます。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>LockMode.NONE represents the absence of a lock. All "
"objects switch to this lock mode at the end of a <literal>Transactionupdate()"
"</literal> or saveOrUpdate() also start out in this lock "
"mode."
msgstr ""
"<literal>LockMode.NONE は、ロックしないことを表します。 "
"<literal>Transaction の終わりに、すべてのオブジェクトはこのロック"
"モードに切り替わります。 <literal>update() や saveOrUpdate"
"()</literal> を呼び出すことによって、セッションに関連付けられたオブジェクト"
"も、このロックモードで出発します。"

#. Tag: para
#, no-c-format
msgid ""
"The \"explicit user request\" is expressed in one of the following ways:"
msgstr "「明示的なユーザー要求」とは、下記の方法の１つで言い表せます。"

#. Tag: para
#, no-c-format
msgid ""
"A call to <literal>Session.load(), specifying a LockMode を指定した Session.load() の呼"
"び出し。"

#. Tag: para
#, no-c-format
msgid "A call to <literal>Session.lock()."
msgstr "<literal>Session.lock() の呼び出し。"

#. Tag: para
#, no-c-format
msgid "A call to <literal>Query.setLockMode()."
msgstr "<literal>Query.setLockMode() の呼び出し。"

#. Tag: para
#, no-c-format
msgid ""
"If <literal>Session.load() is called with UPGRADEUPGRADE_NOWAIT, and the requested object was "
"not yet loaded by the session, the object is loaded using "
"<literal>SELECT ... FOR UPDATE. If load() is "
"called for an object that is already loaded with a less restrictive lock "
"than the one requested, Hibernate calls <literal>lock() for that "
"object."
msgstr ""
"<literal>UPGRADE もしくは UPGRADE_NOWAIT が指定"
"された <literal>Session.load() が呼び出され、かつ要求されたオブジェ"
"クトがセッションによってまだロードされていなかった場合は、 "
"<literal>SELECT ... FOR UPDATE を使って、オブジェクトがロードされま"
"す。 <literal>load() で呼び出されたオブジェクトが、要求されているよ"
"り制限が少ないロックですでにロードされていた場合は、 Hibernate はそのオブジェ"
"クトのために、 <literal>lock() を呼び出します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>Session.lock() performs a version number check if the "
"specified lock mode is <literal>READ, UPGRADE "
"or <literal>UPGRADE_NOWAIT. In the case of UPGRADEUPGRADE_NOWAIT, SELECT ... FOR "
"UPDATE</literal> is used."
msgstr ""
"指定されたロックモードが <literal>READ もしくは、 "
"<literal>UPGRADE 、 UPGRADE_NOWAIT だった場合、 "
"<literal>Session.lock() は、バージョン番号のチェックを実施します。 "
"（<literal>UPGRADE もしくは UPGRADE_NOWAIT の場"
"合、 <literal>SELECT ... FOR UPDATE が使われます。）"

#. Tag: para
#, no-c-format
msgid ""
"If the requested lock mode is not supported by the database, Hibernate uses "
"an appropriate alternate mode instead of throwing an exception. This ensures "
"that applications are portable."
msgstr ""
"データベースが要求されたロックモードをサポートしていない場合、 Hibernate は"
"（例外を投げる代わりに、）適切な代わりのモードを使います。これは、アプリケー"
"ションがポータブルであることを保証します。"

#. Tag: title
#, no-c-format
msgid "Connection release modes"
msgstr "コネクション開放モード"

#. Tag: para
#, no-c-format
msgid ""
"One of the legacies of Hibernate 2.x JDBC connection management meant that a "
"<literal>Session would obtain a connection when it was first "
"required and then maintain that connection until the session was closed. "
"Hibernate 3.x introduced the notion of connection release modes that would "
"instruct a session how to handle its JDBC connections. The following "
"discussion is pertinent only to connections provided through a configured "
"<literal>ConnectionProvider. 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 がコネクションを得るというものでし"
"た。そして、セッションが閉じられるまで、そのコネクションを保持しました。 "
"Hibernate 3.x は、セッションに JDBC コネクションをどのように制御するかを伝え"
"るコネクション開放モードという概念を導入しました。以降の議論は、構成された "
"<literal>ConnectionProvider を通して提供されるコネクションに適切で"
"あることに注意してください。異なる開放モードは、 <literal>org.hibernate."
"ConnectionReleaseMode</literal> に列挙された値により確認されます。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>ON_CLOSE: is the legacy behavior described above. The "
"Hibernate session obtains a connection when it first needs to perform some "
"JDBC access and maintains that connection until the session is closed."
msgstr ""
"<literal>ON_CLOSE - 本質的に上記で述べたレガシーの振る舞いです。 "
"Hibernate セッションは最初に JDBC アクセスを実行する必要がある際にコネクショ"
"ンを得ます。そして、セッションが閉じられるまで、コネクションを保持します。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>AFTER_TRANSACTION: releases connections after a "
"<literal>org.hibernate.Transaction has been completed."
msgstr ""
"<literal>AFTER_TRANSACTION - org.hibernate.Transaction (also referred to as aggressive release): "
"releases connections after 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."
msgstr ""
"<literal>AFTER_STATEMENT （積極的な開放とも呼ばれる） - すべてのス"
"テートメントがそれぞれ実行された後、コネクションが開放されます。ステートメン"
"トがセッションに関連するリソースを開いたままにする場合は、この積極的な開放は"
"スキップされます。今のところ、これが起こるのは <literal>org.hibernate."
"ScrollableResults</literal> が使われる場合のみです。"

#. Tag: para
#, no-c-format
msgid ""
"The configuration parameter <literal>hibernate.connection.release_mode (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. Do not 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 ""
"<literal>auto （デフォルト） - これを選択すると org."
"hibernate.transaction.TransactionFactory.getDefaultReleaseMode()</literal> メ"
"ソッドによって返される開放モードに委譲されます。このメソッドは、 "
"JTATransactionFactory には ConnectionReleaseMode.AFTER_STATEMENT を返し、 "
"JDBCTransactionFactory には ConnectionReleaseMode.AFTER_TRANSACTION を返しま"
"す。このデフォルトの振る舞いを変えてうまくいった試しがありません。それは、こ"
"の設定値が原因で起こる障害は、ユーザーコードの中でバグや間違った条件になりや"
"すいからです。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>on_close: uses ConnectionReleaseMode.ON_CLOSE. This "
"setting is left for backwards compatibility, but its use is discouraged."
msgstr ""
"<literal>on_close - ConnectionReleaseMode.ON_CLOSE を使います。この"
"設定は後方互換のために残されていますが、使わないことを強く勧めます。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>after_transaction: uses 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 ""
"<literal>after_transaction - ConnectionReleaseMode."
"AFTER_TRANSACTION を使います。この設定は JTA 環境の中では使うべきではありませ"
"ん。 ConnectionReleaseMode.AFTER_TRANSACTION を指定し、自動コミットモードの中"
"では、開放モードが AFTER_STATEMENT であるかのように、コネクションは開放される"
"ことに注意してください。"

#. Tag: para
#, no-c-format
msgid ""
"<literal>after_statement: uses ConnectionReleaseMode."
"AFTER_STATEMENT. Additionally, the configured <literal>ConnectionProvider). 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 you make a call into <literal>ConnectionProvider."
"getConnection()</literal> or in auto-commit environments where it does not "
"matter if we re-establish the same connection."
msgstr ""
"<literal>after_statement - ConnectionReleaseMode.AFTER_STATEMENT を"
"使います。さらに、設定された <literal>ConnectionProvider は、この設"
"定 (<literal>supportsAggressiveRelease()) をサポートするかどうかを"
"調べるために使用します。もしそうでない場合、開放モードは "
"ConnectionReleaseMode.AFTER_TRANSACTION にリセットされます。この設定は次の環"
"境でのみ安全です。それは、 <literal>ConnectionProvider.getConnection()

Other Hibernate examples (source code examples)
Here is a short list of links related to this Hibernate transactions.po source code file:

  
 The search page
  
 Other Hibernate source code examples at this package level
  
 Click here to learn more about this project