[jboss-cvs] JBossAS SVN: r75933 - projects/docs/enterprise/4.2/Hibernate/Entity_Manager_User_Guide/ja-JP.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Wed Jul 16 23:14:33 EDT 2008 

Author: tnagamot at redhat.com
Date: 2008-07-16 23:14:33 -0400 (Wed, 16 Jul 2008)
New Revision: 75933

Modified:
   projects/docs/enterprise/4.2/Hibernate/Entity_Manager_User_Guide/ja-JP/Transactions.po
Log:
translation finised

Modified: projects/docs/enterprise/4.2/Hibernate/Entity_Manager_User_Guide/ja-JP/Transactions.po
===================================================================
--- projects/docs/enterprise/4.2/Hibernate/Entity_Manager_User_Guide/ja-JP/Transactions.po	2008-07-17 03:08:51 UTC (rev 75932)
+++ projects/docs/enterprise/4.2/Hibernate/Entity_Manager_User_Guide/ja-JP/Transactions.po	2008-07-17 03:14:33 UTC (rev 75933)
@@ -1,23 +1,25 @@
+# translation of Transactions.po to
 # Language /tmp/mike/JBEAP420/Entity translations for JBEAP package.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008 Free Software Foundation, Inc.
 # Automatically generated, 2007.
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: JBEAP 420\n"
+"Project-Id-Version: Transactions\n"
 "POT-Creation-Date: 2001-02-09 01:25+0100\n"
-"PO-Revision-Date: 2001-02-09 01:25+0100\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: none\n"
+"PO-Revision-Date: 2008-07-16 16:04+1000\n"
+"Last-Translator: Takuro Nagamoto\n"
+"Language-Team:  <ja at 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
 #: Transactions.xml:10
 #, no-c-format
 msgid "Transactions and Concurrency"
-msgstr ""
+msgstr "トランザクションと並行性"
 
 #. Tag: para
 #: Transactions.xml:11
@@ -32,7 +34,7 @@
 "but does not lock objects in memory or change the isolation level of your "
 "database transactions. Basically, use Hibernate Entity Manager like you "
 "would use direct JDBC (or JTA/CMT) with your database resources."
-msgstr ""
+msgstr "Hibernate Entity Manager と並行性制御に関する最も重要な点はその理解のしやすさです。Hibernate Entity Manager は、追加のロック動作を伴わずに JDBC 接続と JTA リソースを直接使用します。JDBC、ANSI、使用しているデータベース管理システムのトランザクション分離の仕様について調べることをお薦めします。Hibernate Entity Manager は自動バージョン管理のみを追加し、メモリ内のオブジェクトをロックしたり、使用しているデータベーストランザクションの分離レベルを変更したりしません。基本的に、使用しているデータベースリソースで直接 JDBC (または JTA/CMT) を使用するように Hibernate Entity Manager を使用してください。"
 
 #. Tag: para
 #: Transactions.xml:14
@@ -43,6 +45,8 @@
 "<literal>EntityManager</literal>, as well as database transactions and long "
 "units of work.."
 msgstr ""
+"Hibernate での並行性制御に関して、まず <literal>EntityManagerFactory</literal> と "
+"<literal>EntityManager</literal> の細分性、およびデータベーストランザクションと長い作業単位について説明します。"
 
 #. Tag: para
 #: Transactions.xml:17
@@ -57,12 +61,14 @@
 "entity manager. Please refer to <xref linkend=\"EJB_container_environment-"
 "Persistence_context_scope\"/> for more information."
 msgstr ""
+"この章では、特に明示的に示されてない限り、エンティティマネージャと永続コンテキストの概念を同じものとして扱います。一方は API とプログラミングオブジェクトであり、もう一方はスコープの定義ですが、基本的な違いがあります。通常、永続コンテキストは Java EE で JTA トランザクションにバインドされ、拡張されたエンティティマネージャを使用しない限り永続コンテキストはトランザクション境界 (トランザクションスコープ) で開始および終了します。詳細については、<xref linkend=\"EJB_container_environment-"
+"Persistence_context_scope\"/> を参照してください。"
 
 #. Tag: title
 #: Transactions.xml:20
 #, no-c-format
 msgid "Entity manager and transaction scopes"
-msgstr ""
+msgstr "エンティティマネージャとトランザクションスコープ"
 
 #. Tag: para
 #: Transactions.xml:21
@@ -71,7 +77,7 @@
 "A <literal>EntityManagerFactory</literal> is an expensive-to-create, "
 "threadsafe object intended to be shared by all application threads. It is "
 "created once, usually on application startup."
-msgstr ""
+msgstr "<literal>EntityManagerFactory</literal> はすべてのアプリケーションスレッドにより共有することが目的の作成にコストがかかるスレッドセーフオブジェクトです。通常は、アプリケーション起動時に 1 度だけ作成されます。"
 
 #. Tag: para
 #: Transactions.xml:24
@@ -87,6 +93,9 @@
 "soon as you are implementing some of the following patterns using request "
 "interception.)"
 msgstr ""
+"<literal>EntityManager</literal> は、単一のビジネスプロセスと単一の作業単位に対して 1 度だけ使用し、破棄するコストがかからない非スレッドセーフオブジェクトです。<literal>EntityManager</literal> は必要でない限り JDBC <literal>Connection</literal> (または、<literal>Datasource</"
+"literal>) を取得しないため、特定の要求に対応するためにデータアクセスが必要でないか確かでない場合でも "
+"<literal>EntityManager</literal> を安全にオープンまたはクローズできます (これは、要求インターセプトを使用して以下の一部のパターンを実装する場合に重要になります)。"
 
 #. Tag: para
 #: Transactions.xml:27
@@ -96,7 +105,7 @@
 "A database transaction has to be as short as possible, to reduce lock "
 "contention in the database. Long database transactions will prevent your "
 "application from scaling to highly concurrent load."
-msgstr ""
+msgstr "これを実現するには、データベーストランザクションについても考える必要があります。データベーストランザクションはできるだけ短くし、データベースでロックが競合する可能性を減らす必要があります。データベーストランザクションが長いと、アプリケーションが高い並行性を持つロードにスケーリングされなくなります。"
 
 #. Tag: para
 #: Transactions.xml:30
@@ -108,12 +117,14 @@
 "<literal>Session</literal> and how do you demarcate the database transaction "
 "boundaries?"
 msgstr ""
+"作業単位のスコープはなんですか? 単一の Hibernate "
+"<literal>EntityManager</literal> が複数のデータベーストランザクションに対応できますか、あるいはこれはスコープの 1 対 1 の関係ですか? いつ <literal>Session</literal> をオープンおよびクローズすべきですか、また、データベーストランザクション境界をどのように設定しますか?"
 
 #. Tag: title
 #: Transactions.xml:33
 #, no-c-format
 msgid "Unit of work"
-msgstr ""
+msgstr "作業単位"
 
 #. Tag: para
 #: Transactions.xml:34
@@ -128,6 +139,10 @@
 "is useless in an application, this mode is intended for ad-hoc SQL console "
 "work.)"
 msgstr ""
+"最初に、<emphasis>entitymanager-per-operation</emphasis> "
+"アンチパターンを使用しないでください。つまり、単一のスレッドで各データベース呼び出しに対して <literal>EntityManager</"
+"literal> をオープンおよびクローズしないでください。当然、データベーストランザクションの場合も同様です。アプリケーションのデータベース呼び出しは、計画された順序で行われ、アトミックな作業単位を使用してグループ分けされます "
+"(これは、各 SQL ステートメント実行後の自動コミットがアプリケーションで必要ないことを意味します。このモードは一時的な SQL コンソールでの作業に向いています)。"
 
 #. Tag: para
 #: Transactions.xml:37
@@ -144,6 +159,8 @@
 "clients request. The relationship between the two is one-to-one and this "
 "model is a perfect fit for many applications."
 msgstr ""
+"マルチユーザークライアント/サーバーアプリケーションでの最も一般的なパターンは "
+"<emphasis>entitymanager-per-request</emphasis> です。このモデルでは、クライアントからの要求がサーバー (EJB3 永続レイヤーが稼働しているサーバー) に送信され、新しい <literal>EntityManager</literal> がオープンし、この作業単位ですべてのデータベース操作が実行されます。作業が終了すると (クライアントへの応答が準備されると)、永続コンテキストとエンティティマネージャがフラッシュされクローズされます。また、クライアント要求に答える単一のデータベーストランザクションも使用できます。これら 2 つの関係は 1 対 1 であり、このモデルは多くのアプリケーションに完全に適合します。"
 
 #. Tag: para
 #: Transactions.xml:40
@@ -155,7 +172,7 @@
 "transaction. The beauty of EJB3 is that you don&#39;t have to care about "
 "that anymore and just see data access through entity manager and demaraction "
 "of transaction scope on session beans as completely orthogonal."
-msgstr ""
+msgstr "これは、Java EE 環境のデフォルトの EJB3 永続モデルです (JTA バインド、トランザクションスコープ永続コンテキスト)。挿入された (または検索された) エンティティマネージャは特定の JTA トランザクションに対して同じ永続コンテキストを共有します。EJB3 の利点は、このことを気にせずに、エンティティマネージャからのデータアクセスとセッション bean のトランザクションスコープの境界設定を完全な直交としてみなすだけでよいことです。"
 
 #. Tag: para
 #: Transactions.xml:43
@@ -184,12 +201,14 @@
 "again, remember that your first choice is naturally an EJB3 container - "
 "preferably a light and modular one such as JBoss application server."
 msgstr ""
+"EJB3 コンテナ外部にこの (および他の) 動作を実装することは困難です。<literal>EntityManager</literal> とリソースローカルトランザクションを正常に起動および終了する必要があるだけでなく、これらがデータアクセス操作でアクセス可能である必要があります。作業単位の境界は、理想的には要求が非 EJB3 コンテナサーバーに到達し、応答が送信される前に実行されるインターセプタを使用して実装されます (たとえば、スタンドアロンサーブレットコンテナを使用している場合は <literal>ServletFilter</literal>)。<literal>ThreadLocal</literal> 変数を使用して <literal>EntityManager</literal> を要求に答えるスレッドにバインドすることをお薦めします。これにより、このスレッドで実行されるすべてのコードでアクセスを (静的変数にアクセスするように) !
 簡単に行えるようになります。選択したデータベーストランザクション境界メカニズムに応じて、トランザクションコンテキストを <literal>ThreadLocal</literal> 変数に保持することもできます。これに対する実装パターンは Hibernate コミュニティでは <emphasis>ThreadLocal Session</emphasis> と "
+"<emphasis>Open Session in View</emphasis> として知られています。このパターンを実装するために、Hibernate リファレンスドキュメントに示されている <literal>HibernateUtil</literal> を簡単に拡張できます。外部ソフトウェアは必要ありません (実際にはこのことは重要ではありません)。当然のことながら、インターセプタを実装し、自分の環境で設定する方法を見つける必要があります。ヒントと例については、Hibernate の Web サイトを参照してください。もう一度いいますが、最初は当然 EJB3 コンテナ (理想的には JBoss アプリケーションサーバーなどの単純でモジュール形式のもの) を選択してください。"
 
 #. Tag: title
 #: Transactions.xml:46
 #, no-c-format
 msgid "Long units of work"
-msgstr ""
+msgstr "長い作業単位"
 
 #. Tag: para
 #: Transactions.xml:47
@@ -201,7 +220,7 @@
 "enterprise applications it is not acceptable for a database transaction to "
 "span a user interaction with possibly long waiting time between requests. "
 "Consider the following example:"
-msgstr ""
+msgstr "1 つの要求あたり 1 つのエンティティマネージャのパターンは、作業単位を設計するのに使用できる唯一の役に立つコンセプトではありません。多くのビジネスプロセスは、データベースアクセスを介したユーザーとの一連の対話を必要とします。Web とエンタープライズアプリケーションでは、データベーストランザクションで、場合によっては要求と要求の間に長い待機時間を伴うユーザーとの対話は許容されません。以下の例を考えてください。"
 
 #. Tag: para
 #: Transactions.xml:52
@@ -210,7 +229,7 @@
 "The first screen of a dialog opens, the data seen by the user has been "
 "loaded in a particular <literal>EntityManager</literal> and resource-local "
 "transaction. The user is free to modify the detached objects."
-msgstr ""
+msgstr "ダイアログの最初の画面が表示され、ユーザーが参照するデータが特定の <literal>EntityManager</literal> とリソースローカルトランザクションにロードされます。ユーザーは接続解除されたオブジェクトを自由に変更できます。"
 
 #. Tag: para
 #: Transactions.xml:57
@@ -219,7 +238,7 @@
 "The user clicks \"Save\" after 5 minutes and expects his modifications to be "
 "made persistent; he also expects that he was the only person editing this "
 "information and that no conflicting modification can occur."
-msgstr ""
+msgstr "5 分後にユーザーが \"Save\" をクリックし、変更内容が反映されるようにします。また、ユーザーはこの情報を編集しているのがユーザーだけであり、変更の競合が発生しないことを期待します。"
 
 #. Tag: para
 #: Transactions.xml:62
@@ -228,7 +247,7 @@
 "We call this unit of work, from the point of view of the user, a long "
 "running <emphasis>application transaction</emphasis>. There are many ways "
 "how you can implement this in your application."
-msgstr ""
+msgstr "これは、ユーザーの観点からは作業単位 (長く実行されているアプリケーショントランザクション) と呼ばれます。これをアプリケーションに実装するには多くの方法があります。"
 
 #. Tag: para
 #: Transactions.xml:65
@@ -240,7 +259,7 @@
 "atomicity. This is of course an anti-pattern, a pessimistic approach, since "
 "lock contention would not allow the application to scale with the number of "
 "concurrent users."
-msgstr ""
+msgstr "経験がない場合は、最初に、ユーザーが考えてる間 <literal>EntityManager</literal> とデータベーストランザクションをオープンの状態にするよう実装してしまうかもしれません。この場合は、変更が同時に行われることを防ぎ、分離と原子性を保証するためにデータベースにロックがかかります。これは、ロックの競合によりアプリケーションがたくさんの同時ユーザーに対応できないため、当然アンチパターンで悲観的なアプローチです。"
 
 #. Tag: para
 #: Transactions.xml:68
@@ -255,7 +274,7 @@
 "dialog spanning several request/response cycles). This is easier to "
 "implement than it might sound, especially if you use EJB3 entity manager and "
 "persistence context features:"
-msgstr ""
+msgstr "明らかにアプリケーショントランザクションを実装するには複数のデータベーストランザクションを使用する必要があります。この場合、アプリケーション層は部分的にビジネスプロセスの分離に責任があります。通常、1 つのアプリケーショントランザクションには、複数のデータベーストランザクションが関係します。これらのデータベーストランザクションの 1 つ (最後のトランザクション) が更新されたデータを格納する場合に、他のすべてのトランザクションが単にデータを読み取る (たとえば、複数の要求/応答サイクルに関係するウィザード形式のダイアログで) 場合は、原子性があるといえます。これは、特に EJB3 エンティティマネージャと永続コンテキスト機能を使用している場合は考えているよりも簡単に実装!
 できます。"
 
 #. Tag: para
 #: Transactions.xml:73
@@ -266,7 +285,7 @@
 "detect if a concurrent modification occured during user think time (usually "
 "by comparing version numbers or timestamps when updating the data in the "
 "final resource-local transaction)."
-msgstr ""
+msgstr "<emphasis>自動バージョン管理</emphasis> - エンティティマネージャには自動オプティミスティック並行性制御が含まれます。エンティティマネージャは、ユーザーが考えているときに同時変更が行われたかどうかを自動的に検出します (通常は、最後のリソースローカルトランザクションでのデータの更新時にバージョン番号またはタイムスタンプを比較します)。"
 
 #. Tag: para
 #: Transactions.xml:78
@@ -280,6 +299,8 @@
 "with-detached-entities</emphasis>. Automatic versioning is used to isolate "
 "concurrent modifications."
 msgstr ""
+"<emphasis>接続解除されたエンティティ</emphasis> - すでに説明した <emphasis>entity-per-request</emphasis> パターンを使用する場合は、ロードされたすべてのインスタンスはユーザーが考えている時間は接続解除された状態になります。エンティティマネージャでは、接続解除された (変更された) 状態をマージし、変更を永続可できます。このパターンは <emphasis>entitymanager-per-request-"
+"with-detached-entities</emphasis> と呼ばれます。自動バージョン管理は同時変更を分離するために使用されます。"
 
 #. Tag: para
 #: Transactions.xml:83
@@ -296,6 +317,9 @@
 "queued modifications. Automatic versioning is used to isolate concurrent "
 "modifications."
 msgstr ""
+"<emphasis>æ‹¡å¼µ Entity Manager</emphasis> - Hibernate Entity Manager "
+"は、2 つのクライアント呼び出しの間に基礎となる JDBC 接続から接続解除し、新しいクライアント要求が発生したときに再び接続できます。このパターンは <emphasis>entitymanager-per-application-transaction</emphasis> と呼ばれ、マージは不必要になります。拡張された永続コンテキストはトランザクション外で行われたすべての変更 (永続化、マージ、削除) を収集および保持します。アクティブなトランザクション内で次のクライアント呼び出しが発生すると "
+"(通常はユーザー対話の最後の操作)、キューで待機状態のすべての変更が実行されます。自動バージョン管理は、同時変更を分離するために使用されます。"
 
 #. Tag: para
 #: Transactions.xml:88
@@ -306,18 +330,20 @@
 "advantages and disadvantages, we discuss them later in this chapter in the "
 "context of optimistic concurrency control."
 msgstr ""
+"<emphasis>entitymanager-per-request-with-detached-objects</emphasis> "
+"と <emphasis>entitymanager-per-application-transaction</emphasis> には、利点と欠点があります。このことについては、この章のオプティミスティック並行性制御に関する記述で説明します。"
 
 #. Tag: para
 #: Transactions.xml:91
 #, no-c-format
 msgid "TODO: This note should probably come later."
-msgstr ""
+msgstr "  "
 
 #. Tag: title
 #: Transactions.xml:94
 #, no-c-format
 msgid "Considering object identity"
-msgstr ""
+msgstr "オブジェクト ID の考慮"
 
 #. Tag: para
 #: Transactions.xml:95
@@ -327,31 +353,31 @@
 "different persistence contexts. However, an instance of a managed class is "
 "never shared between two persistence contexts. Hence there are two different "
 "notions of identity:"
-msgstr ""
+msgstr "アプリケーションは 2 つの異なる永続コンテキストの同じ永続ステータスに同時にアクセスできます。ただし、管理されたクラスのインスタンスは 2 つの永続コンテキスト間では共有されません。したがって、ID の表記には以下の 2 つの種類があります。"
 
 #. Tag: term
 #: Transactions.xml:100
 #, no-c-format
 msgid "Database Identity"
-msgstr ""
+msgstr "データベース ID"
 
 #. Tag: literal
 #: Transactions.xml:103
 #, no-c-format
 msgid "foo.getId().equals( bar.getId() )"
-msgstr ""
+msgstr "foo.getId().equals( bar.getId() )"
 
 #. Tag: term
 #: Transactions.xml:108
 #, no-c-format
 msgid "JVM Identity"
-msgstr ""
+msgstr "JVM ID"
 
 #. Tag: literal
 #: Transactions.xml:111
 #, no-c-format
 msgid "foo==bar"
-msgstr ""
+msgstr "foo==bar"
 
 #. Tag: para
 #: Transactions.xml:116
@@ -365,7 +391,7 @@
 "two different persistence contexts, the two instances will actually be "
 "\"different\" (JVM identity). Conflicts are resolved using (automatic "
 "versioning) at flush/commit time, using an optimistic approach."
-msgstr ""
+msgstr "<emphasis></emphasis>特定の永続コンテキスト (<literal>EntityManager</literal> のスコープ内) に接続されたオブジェクトの場合、2 つの表記は同じになり、データベース ID に対する JVM ID は Hibernate Entity Manager によって保証されます。ただし、アプリケーションが 2 つの異なる永続コンテキストの「同じ」 (永続 ID) ビジネスオブジェクトに同時にアクセスできる一方で、実際には2 つのインスタンスは異なります (JVM ID)。コンフリクトはフラッシュ/コミット時にオプティミスティックアプローチを使用して解決されます (自動バージョン管理を使用)。"
 
 #. Tag: para
 #: Transactions.xml:119
@@ -379,6 +405,8 @@
 "<literal>EntityManager</literal>. Within a persistence context, the "
 "application may safely use <literal>==</literal> to compare entities."
 msgstr ""
+"このアプローチにより、並行性については Hibernate とデータベースに任せることになります。また、単一のスレッド化された作業単位で ID を保証するにはコストがかかるロックまたは他の同期の手段が必要となるため、最良のスケーラビリティが提供されます。1 つの "
+"<literal>EntityManager</literal> に対して 1 つのスレッドを使用する限り、アプリケーションはどのビジネスオブジェクトでも同期する必要がありません。永続コンテキスト内で、アプリケーションはエンティティを比較する <literal>==</literal> を安全に使用できます。"
 
 #. Tag: para
 #: Transactions.xml:122
@@ -405,12 +433,16 @@
 "that this is not a Hibernate issue, but simply how Java object identity and "
 "equality has to be implemented."
 msgstr ""
+"ただし、永続コンテキストの外部で <literal>==</literal> を使用するアプリケーションでは予期しない結果が起こることがあります。これは、一部の予期しない場合にも起こります。たとえば、2 つの接続解除されたインスタンスを同じ <literal>Set</literal> に格納した場合などです。両方とも同じデータベース ID を持ちますが (つまり、同じ行を表す)、JVM ID は定義により接続解除された状態のインスタンスに対して保証されません。開発者は永続クラスで <literal>equals()</literal> メソッドと <literal>hashCode()</literal> メソッドをオーバライドし、オブジェクト等価性の独自の表記を実装する必要があります。ここで注意すべきことは、等価性を実装するためにデータベース ID を使用せず、ビジネスキー (通常は変更されない一意の属性の組み合わ!
 せ) を使用することです。データベース ID は、一時エンティティが永続化された場合に変わります "
+"(<literal>persist()</literal> 操作のコントラクトを参照)。一時インスタンス (通常は接続解除されたインスタンスとともに使用) が "
+"<literal>Set</literal> に格納される場合は、ハッシュコードを変更すると"
+"<literal>Set</literal> のコントラクトが破壊されます。優れたビジネスキーの属性はデータベースのプライマリキーほど安定的である必要はありません。オブジェクトが同じ <literal>Set</literal> に含まれる場合にのみ安定性を保証する必要があります。この問題の詳細については、Hibernate の Web サイトを参照してください。また、これは Hibernate の問題ではなく、単に Java オブジェクト ID と等価性をどのように実装しなければならないかということに注意してください。"
 
 #. Tag: title
 #: Transactions.xml:125
 #, no-c-format
 msgid "Common concurrency control issues"
-msgstr ""
+msgstr "一般的な並行性制御の問題"
 
 #. Tag: para
 #: Transactions.xml:126
@@ -424,6 +456,8 @@
 "appear with the recommended patterns, make sure you understand the "
 "implications before making a design decision:"
 msgstr ""
+"アンチパターン <emphasis>entitymanager-per-user-session</"
+"emphasis> または <emphasis>entitymanager-per-application</emphasis> を使用しないでください (当然、このルールには例外があります。たとえば、永続コンテキストを手動でフラッシュして entitymanager-per-application をデスクトップアプリケーションで使用可能にする場合など)。また、推奨されたパターンで以下の問題がいくつか生じることがあります。設計に関する決定を下す前にその影響について理解してください。"
 
 #. Tag: para
 #: Transactions.xml:131
@@ -438,7 +472,7 @@
 "reload fast enough may use the same <literal>EntityManager</literal> in two "
 "concurrently running threads. You will very likely have provisions for this "
 "case already in place, for other non-threadsafe but session-scoped objects."
-msgstr ""
+msgstr "エンティティマネージャはスレッドセーフではありません。<literal>EntityManager</literal> インスタンスを共有する場合は、HTTP 要求、セッション Bean、Swing ワーカーなどの同時に動作するものにより、競合が発生します。 Hibernate <literal>EntityManager</literal>をr <literal>HttpSession</literal> 後で説明r に保持する場合は、 Httpセッションへのアクセスを同期することを考慮する必要があります。そもないと、リロードを素早くクリックしたユーザーが同じ 2 つの同時実行スレッドで同じe <literal>EntityManager</literal>を使用することがあります。他の非スレッドセーフでセッションスコープのオブジェクトの場合は、すでにこれに該当している可能性が高くなります。."
 
 #. Tag: para
 #: Transactions.xml:136
@@ -455,6 +489,8 @@
 "recoverable and you have to start over your unit of work after rollback "
 "anyway."
 msgstr ""
+"Entity Manager によってスローされた例外は、データベーストランザクションをロールバックし、<literal>EntityManager</literal> "
+"をすぐに閉じなければならないことを意味します (後で詳述します)。<literal>EntityManager</literal> がアプリケーションにバインドされる場合は、アプリケーションを停止する必要があります。データベーストランザクションをロールバックすると、ビジネスオブジェクトがトランザクションの開示時の状態に戻りません。つまり、データベースの状態とビジネスオブジェクトが同期されません。例外は復元可能ではなく、ロールバック後は作業単位をやり直す必要があるため、通常これは問題になりません。"
 
 #. Tag: para
 #: Transactions.xml:141
@@ -472,12 +508,14 @@
 "probability of stale data, which you have to know about and control "
 "appropriately."
 msgstr ""
+"永続コンテキストは、管理された状態にある各オブジェクトをキャッシュします "
+"(Hibernate がダーティな状態を監視およびチェックします)。これは、長い間オープンにしたり、非常にたくさんのデータを単にロードしたりした場合に <classname>OutOfMemoryException</classname> が発生するまで引き続きデータが大きくなることを意味します。この問題の 1 つの解決策は永続コンテキストの定期的なフラッシュの一種のバッチ処理ですが、大量のデータ処理が必要な場合は、データベースのストアドプロシージャの使用を検討してください。この問題の解決策のいくつかは <xref linkend=\"Batch_processing\"/> に示されています。また、ユーザーセッションの間永続コンテキストをオープンにしたままだと、不整合なデータが発生する可能性が高くなります (この問題について調べ、適切に対処する必要があります)。"
 
 #. Tag: title
 #: Transactions.xml:146
 #, no-c-format
 msgid "Database transaction demarcation"
-msgstr ""
+msgstr "データベーストランザクションの境界"
 
 #. Tag: para
 #: Transactions.xml:147
@@ -493,6 +531,8 @@
 "transaction, though, when you&#39;ll need to retain modifications in an "
 "<literal>EXTENDED</literal> persistence context."
 msgstr ""
+"データベース (またはシステム) トランザクション境界は常に必要です。データベーストランザクションの外部ではデータベースとの通信を行うことができません "
+"(多くの開発者は自動コミットモードに慣れているため混乱します)。読み取り専用操作の場合であっても常に明確なトランザクション境界を使用してください。分離レベルとデータベースの機能に応じて、これは必要にならない場合もありますが、常にトランザクションの境界を明示的に設定しても問題ありません。<literal>EXTENDED</literal> 永続コンテキストで変更を保持する必要がある場合は、トランザクションの外部で操作を実行する必要があります。"
 
 #. Tag: para
 #: Transactions.xml:150
@@ -508,13 +548,13 @@
 "defined declaratively through annotations of EJB session beans, for example. "
 "Programmatic transaction demarcation is then no longer necessary, even "
 "flushing the <literal>EntityManager</literal> is done automatically."
-msgstr ""
+msgstr "EJB3 アプリケーションは、管理されてない (スタンドアロン、単純な Web アプリケーション、または Swing アプリケーション) J2EE 環境と管理された J2EE 環境で実行できます。管理されていない環境では、通常 <literal>EntityManagerFactory</literal> が独自のデータベース接続プールを処理します。アプリケーション開発者は、手動でトランザクション境界を設定する必要があります。つまり、自分でデータベーストランザクションの開始、コミット、またはロールバックを実行する必要があります。管理された環境は通常コンテナ管理トランザクションを提供し、トランザクションアセンブリが EJB セッション Bean などのアノテーションを介して宣言されます。プログラムによるトランザクション境界設定は、<literal>EntityManager</literal> のフãƒ!
 ©ãƒƒã‚·ãƒ¥ãŒè‡ªå‹•çš„に行われた場合であっても必要なくなります。"
 
 #. Tag: para
 #: Transactions.xml:153
 #, no-c-format
 msgid "Usually, ending a unit of work involves four distinct phases:"
-msgstr ""
+msgstr "通常、作業単位の終了は 4 つの明確な段階から構成されます。"
 
 #. Tag: para
 #: Transactions.xml:158
@@ -522,20 +562,19 @@
 msgid ""
 "commit the (resource-local or JTA) transaction (this automatically flushes "
 "the entity manager and persistence context)"
-msgstr ""
+msgstr "(リソースローカルまたは JTA) トランザクションのコミット (エンティティマネージャと永続コンテキストが自動的にフラッシュされます)"
 
 #. Tag: para
 #: Transactions.xml:163
 #, no-c-format
-msgid ""
-"close the entity manager (if using an application-managed entity manager)"
-msgstr ""
+msgid "close the entity manager (if using an application-managed entity manager)"
+msgstr "エンティティマネージャのクローズ (アプリケーション管理エンティティマネージャを使用している場合)"
 
 #. Tag: para
 #: Transactions.xml:168
 #, no-c-format
 msgid "handle exceptions"
-msgstr ""
+msgstr "例外処理"
 
 #. Tag: para
 #: Transactions.xml:173
@@ -543,13 +582,13 @@
 msgid ""
 "We&#39;ll now have a closer look at transaction demarcation and exception "
 "handling in both managed- and non-managed environments."
-msgstr ""
+msgstr "ここでは、管理された環境と管理されていない環境の両方でのトランザクション境界設定と例外処理について説明します。"
 
 #. Tag: title
 #: Transactions.xml:176
 #, no-c-format
 msgid "Non-managed environment"
-msgstr ""
+msgstr "管理されていない環境"
 
 #. Tag: para
 #: Transactions.xml:177
@@ -559,7 +598,7 @@
 "connections are usually handled by Hibernate&#39;s pooling mechanism behind "
 "the scenes. The common entity manager and transaction handling idiom looks "
 "like this:"
-msgstr ""
+msgstr "EJB3 永続レイヤが管理されていない環境で実行されている場合、通常データベース接続は Hibernate のプーリングメカニズムによって自動的に処理されます。エンティティマネージャとトランザクション処理の一般的なコードは以下のようになります。"
 
 #. Tag: programlisting
 #: Transactions.xml:180
@@ -585,6 +624,25 @@
 "    em.close();\n"
 "}"
 msgstr ""
+"// Non-managed environment idiom\n"
+"EntityManager em = emf.createEntityManager();\n"
+"EntityTransaction tx = null;\n"
+"try {\n"
+"    tx = em.getTransaction();\n"
+"    tx.begin();\n"
+"\n"
+"    // do some work\n"
+"    ...\n"
+"\n"
+"    tx.commit();\n"
+"}\n"
+"catch (RuntimeException e) {\n"
+"    if ( tx != null &amp;&amp; tx.isActive() ) tx.rollback();\n"
+"    throw e; // or display error message\n"
+"}\n"
+"finally {\n"
+"    em.close();\n"
+"}"
 
 #. Tag: para
 #: Transactions.xml:181
@@ -594,6 +652,8 @@
 "literal> explicitly - the call to <literal>commit()</literal> automatically "
 "triggers the synchronization."
 msgstr ""
+"You don&#39;t have tothe <literal>EntityManager</"
+"literal> に対して明示的に <literal>flush()</literal> を実行する必要はありません。<literal>commit()</literal> の呼び出しにより同期が自動的にトリガされます。"
 
 #. Tag: para
 #: Transactions.xml:184
@@ -604,6 +664,8 @@
 "literal> is the release of resources - make sure you always close and never "
 "outside of guaranteed finally block."
 msgstr ""
+"<literal>close()</literal> を呼び出すと、<literal>EntityManager</literal> が終了します。<literal>close()</"
+"literal> の主な目的はリソースの解放です。常にクローズし、保証された finally ブロックの外部に出ないようにしてください。"
 
 #. Tag: para
 #: Transactions.xml:187
@@ -618,12 +680,15 @@
 "container services whenever they are available. Exception handling is "
 "discussed later in this chapter."
 msgstr ""
+"通常のアプリケーションでは、ビジネスコードでこのイディオムが使用されることはほとんどありません。重大な (システム) 例外は常に「上部」で捕捉しなければなりません。つまり、エンティティマネージャ呼び出しを実行するコード (永続レイヤ) と <literal>RuntimeException</"
+"literal> を処理するコード (通常、その他にクリーンアップと終了のみ実行できます) は異なるレイヤに存在します。これにより設計は困難になります。できるだけ J2EE/EJB "
+"コンテナサービスを使用してください。例外処理については、この章の後半で説明します。"
 
 #. Tag: title
 #: Transactions.xml:190
 #, no-c-format
 msgid "EntityTransaction"
-msgstr ""
+msgstr "EntityTransaction"
 
 #. Tag: para
 #: Transactions.xml:191
@@ -632,7 +697,7 @@
 "In a JTA environment, you don&#39;t need any extra API to interact with the "
 "transaction in your environment. Simply use transaction declaration or the "
 "JTA APIs."
-msgstr ""
+msgstr "JTA 環境では、使用している環境のトランザクションと対話するために API を追加する必要がありません。単にトランザクション宣言または JTA API を使用してください。"
 
 #. Tag: para
 #: Transactions.xml:194
@@ -653,6 +718,13 @@
 "will try to rollback the transaction and raise a <literal>javax.transaction."
 "RollbackException</literal>."
 msgstr ""
+"<literal>RESOURCE_LOCAL</literal> エンティティマネージャを使用している場合は、<literal>EntityTransaction</literal> API を使用してトランザクション境界を設定する必要があります。<literal>EntityTransaction</literal> は <literal>entityManager."
+"getTransaction()</literal> を介して取得できます。この <literal>EntityTransaction</literal> API は通常の <methodname>begin()</methodname> メソッド、<methodname>commit()</"
+"methodname> メソッド、<methodname>rollback()</methodname> メソッド、<methodname>isActive()</"
+"methodname> メソッドを提供します。また、この API を使用すると、トランザクションをロールバックのみに指定し、トランザクションがロールバックすることを強制できます。これは、JTA 操作 <methodname>setRollbackOnly()</methodname> に非常に似ています。<literal>commit"
+"()</literal> 操作が失敗した場合、またはトランザクションが "
+"<literal>setRollbackOnly()</literal> として指定された場合は、<literal>commit()</literal> メソッドがトランザクションをロールバックしようとし、<literal>javax.transaction."
+"RollbackException</literal> を発生させます。"
 
 #. Tag: para
 #: Transactions.xml:197
@@ -661,12 +733,14 @@
 "In a <literal>JTA</literal> entity manager, <literal>entityManager."
 "getTransaction()</literal> calls are not permitted."
 msgstr ""
+"<literal>JTA</literal> エンティティマネージャでは、<literal>entityManager."
+"getTransaction()</literal> 読み出しは許可されません。"
 
 #. Tag: title
 #: Transactions.xml:200
 #, no-c-format
 msgid "Using JTA"
-msgstr ""
+msgstr "JTA の使用"
 
 #. Tag: para
 #: Transactions.xml:201
@@ -676,14 +750,13 @@
 "session beans), every datasource connection obtained internally by the "
 "entity manager will automatically be part of the global JTA transaction. "
 "Hibernate offers two strategies for this integration."
-msgstr ""
+msgstr "永続レイヤがアプリケーションサーバー (EJB3 セッション Bean の背後など) で実行する場合、エンティティマネージャによって内部的に取得された各データソース接続は自動的に JTA トランザクションの一部になります。この統合のために Hibernate では 2 つの方針が提供されます。"
 
 #. Tag: para
 #: Transactions.xml:204
 #, no-c-format
-msgid ""
-"If you use bean-managed transactions (BMT), the code will look like this:"
-msgstr ""
+msgid "If you use bean-managed transactions (BMT), the code will look like this:"
+msgstr "Bean 管理トランザクション (BMT) を使用する場合は、以下のようなコードになります。"
 
 #. Tag: programlisting
 #: Transactions.xml:207
@@ -710,6 +783,26 @@
 "    em.close();\n"
 "}"
 msgstr ""
+"// BMT イディオム\n"
+"@Resource public UserTransaction utx;\n"
+"@Resource public EntityManagerFactory factory;\n"
+"\n"
+"public void doBusiness() {\n"
+"    EntityManager em = factory.createEntityManager();\n"
+"    try {\n"
+"\n"
+"    // なんらかの処理を行う\n"
+"    ...\n"
+"\n"
+"    utx.commit();\n"
+"}\n"
+"catch (RuntimeException e) {\n"
+"    if (utx != null) utx.rollback();\n"
+"    throw e; // or display error message\n"
+"}\n"
+"finally {\n"
+"    em.close();\n"
+"}"
 
 #. Tag: para
 #: Transactions.xml:208
@@ -726,6 +819,8 @@
 "<literal>RuntimeException</literal>s they will rollback the transaction as "
 "per the EJB specification (system exception vs. application exception)."
 msgstr ""
+"EJB3 コンテナで Container Managed Transactions (CMT) を使用すると、プログラムを使用せずにトランザクション境界をセッション Bean アノテーションまたはデプロイメント記述子で設定できます。<literal>EntityManager</literal> はトランザクションの完了時に自動的にフラッシュされます (<literal>EntityManager</literal> を挿入またはルックアップした場合は、自動的にクローズします)。<literal>EntityManager</literal> の使用時に例外が発生した場合、例外を捕捉しないとトランザクションロールバックが自動的に実行されます。<literal>EntityManager</literal> 例外は "
+"<literal>RuntimeException</literal> であるため、EJB の仕様 (システム例外 vs アプリケーション例外) に基づいてトランザクションがロールバックされます。"
 
 #. Tag: para
 #: Transactions.xml:211
@@ -736,6 +831,9 @@
 "to also set <literal>org.hibernate.transaction.manager_lookup_class</"
 "literal>."
 msgstr ""
+"Hibernate EntityManager により <literal>hibernate."
+"transaction.factory_class</literal> を定義することが重要です (つまり、この値をオーバーライドしないでください)。<literal>org.hibernate.transaction.manager_lookup_class</"
+"literal> を設定することにも注意してください。"
 
 #. Tag: para
 #: Transactions.xml:214
@@ -752,6 +850,8 @@
 "new one and bind it (see <xref linkend=\"EJB_container_environment-"
 "Persistence_context_propagation\"/> .)"
 msgstr ""
+"CMT 環境で作業をする場合は、コードのさまざまな部分で同じエンティティマネージャを使用することもできます。通常、管理されていない環境では、エンティティマネージャを保持するために <literal>ThreadLocal</literal> 変数を使用しますが、単一の EJB 要求はさまざまスレッド (たとえば、別のセッション Bean を呼び出すセッション Bean など) で実行できます。EJB3 コンテナは、永続コンテキストを伝搬します。EJB3 コンテナは、挿入またはルックアップを使用してエンティティマネージャに JTA コンテキスト (存在する場合) にバインドされた同じ永続コンテキストを返すか、新しい永続コンテキストを作成し、バインドします (<xref linkend=\"EJB_container_environment-"
+"Persistence_context_propagation\"/> を参照)。"
 
 #. Tag: para
 #: Transactions.xml:217
@@ -759,7 +859,7 @@
 msgid ""
 "Our entity manager/transaction management idiom for CMT and EJB3 container-"
 "use is reduced to this:"
-msgstr ""
+msgstr "CMT と EJB3 コンテナの使用に関するエンティティマネージャ/トランザクション管理イディオムは以下のように短縮されます。"
 
 #. Tag: programlisting
 #: Transactions.xml:220
@@ -768,6 +868,8 @@
 "//CMT idiom through injection\n"
 "@PersistenceContext(name=\"sample\") EntityManager em;"
 msgstr ""
+"//挿入を伴う CMT イディオム\n"
+"@PersistenceContext(name=\"sample\") EntityManager em;"
 
 #. Tag: para
 #: Transactions.xml:221
@@ -779,14 +881,13 @@
 "annotations or deployment descriptors of your session beans. The lifecycle "
 "of the entity manager and persistence context is completely managed by the "
 "container."
-msgstr ""
+msgstr "つまり、管理された環境では、<literal>EntityManager</literal> を挿入し、データアクセスの作業を行うだけでよく、残りの処理はコンテナに任せることができます。トランザクション境界は、セッション Bean のアノテーションまたはデプロイメント記述子で明示的に設定されます。エンティティマネージャと永続コンテキストのライフサイクルはコンテナによって完全に管理されます。"
 
 #. Tag: para
 #: Transactions.xml:224
 #, no-c-format
-msgid ""
-"TODO: The following paragraph is very confusing, especially the beginning..."
-msgstr ""
+msgid "TODO: The following paragraph is very confusing, especially the beginning..."
+msgstr "  "
 
 #. Tag: para
 #: Transactions.xml:227
@@ -804,12 +905,16 @@
 "easily avoid using <literal>scroll()</literal> or <literal>iterate()</"
 "literal> at all from the CMT code.)"
 msgstr ""
+"特定の Hibernate ネイティブ API を使用する場合、<literal>after_statement</literal> 接続解除モードが重要になります。JTA の仕様の制限により、Hibernate でクローズされていない <literal>ScrollableResults</literal> や <literal>scroll()</"
+"literal> または <literal>iterate()</literal> によって返された <literal>Iterator</literal> インスタンスを自動的にクリーンアップすることができません。<emphasis></emphasis>基礎となるデータベースカーソルは、<literal>finally</literal> ブロックから明示的に <literal>ScrollableResults."
+"close()</literal> または <literal>Hibernate.close(Iterator)</literal> を呼び出すことにより解放する必要があります (当然、ほとんどのアプリケーションでは、CMT コードから <literal>scroll()</literal> または <literal>iterate()</"
+"literal> を使用することを簡単に回避できます)。"
 
 #. Tag: title
 #: Transactions.xml:230
 #, no-c-format
 msgid "Exception handling"
-msgstr ""
+msgstr "例外処理"
 
 #. Tag: para
 #: Transactions.xml:231
@@ -828,6 +933,9 @@
 "managed entity manager will do that for you. You just have to let the "
 "RuntimeException propagate up to the container."
 msgstr ""
+"<literal>EntityManager</literal> が例外 (任意の "
+"<literal>SQLException</literal> を含む) をスローした場合、データベーストランザクションをすぐにロールバックし、<literal>EntityManager.close()</literal> (<methodname>createEntityManager()</methodname> が呼び出された場合) を呼び出して、<literal>EntityManager</literal> インスタンスを破棄する必要があります。<literal>EntityManager</literal> の特定のメソッドは、永続コンテキストを一定の状態に保ちません。エンティティマネージャによって例外がスローされない場合は、回復可能であるとみなされます。<literal>finally</literal> ブロックで <literal>close()</"
+"literal> を呼び出して <literal>EntityManager</literal> がクローズされるようにしてください。ただし、この処理はコンテナ管理エンティティマネージャによって行われます。他に必要なことは RuntimeException がコンテナに伝搬するようにするだけです。"
 
 #. Tag: para
 #: Transactions.xml:234
@@ -836,13 +944,13 @@
 "The Hibernate entity manager generally raises exceptions which encapsulate "
 "the Hibernate core exception. Common exceptions raised by the "
 "<literal>EntityManager</literal> API are"
-msgstr ""
+msgstr "通常、Hibernate エンティティマネージャは、Hibernate の中核的な例外をカプセル化する例外を発生させます。<literal>EntityManager</literal> API によって発生する一般的な例外は以下のとおりです。"
 
 #. Tag: para
 #: Transactions.xml:239
 #, no-c-format
 msgid "IllegalArgumentException: something wrong happen"
-msgstr ""
+msgstr "IllegalArgumentException: 何らかのエラーが発生"
 
 #. Tag: para
 #: Transactions.xml:244
@@ -850,19 +958,19 @@
 msgid ""
 "EntityNotFoundException: an entity was expected but none match the "
 "requirement"
-msgstr ""
+msgstr "EntityNotFoundException: エンティティが期待されたが要件を満たすものがなかった"
 
 #. Tag: para
 #: Transactions.xml:249
 #, no-c-format
 msgid "TransactionRequiredException: this operation has to be in a transaction"
-msgstr ""
+msgstr "TransactionRequiredException: この処理はトランザクションで行わなければならない"
 
 #. Tag: para
 #: Transactions.xml:254
 #, no-c-format
 msgid "IllegalStateException: the entity manager is used in a wrong way"
-msgstr ""
+msgstr "IllegalStateException: エンティティマネージャの使用方法が間違っている"
 
 #. Tag: para
 #: Transactions.xml:259
@@ -873,7 +981,7 @@
 "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 ""
+msgstr "Hibernate 永続レイヤで発生するほとんどのエラーをラップする <literal>HibernateException</literal> は、チェックされない例外です。Hibernate は、<literal>HibernateException</literal> でない他の未チェックの例外もスローできることに注意してください。繰り返しますが、これらは回復不可能なので、適切な処置を講じる必要があります。"
 
 #. Tag: para
 #: Transactions.xml:262
@@ -894,6 +1002,11 @@
 "class for details). The standard <literal>JDBCException</literal> subtypes "
 "are:"
 msgstr ""
+"Hibernate は、<literal>JDBCException</literal> でデータベースと対話しているときにスローされる <literal>SQLException</literal> をラップします。実際には、Hibernate はこの例外を "
+"<literal>JDBCException</literal> の意味があるサブクラスに変換しようとします。基礎となる <literal>SQLException</"
+"literal> は常に <literal>JDBCException.getCause()</"
+"literal> で利用できます。Hibernate は、<literal>SessionFactory</literal> に接続された <literal>SQLExceptionConverter</literal> を使用して <literal>SQLException</literal> を適切な <literal>JDBCException</literal> サブクラスに変換します。デフォルトでは、<literal>SQLExceptionConverter</literal> は設定されたダイアレクトにより定義されますが、カスタム実装を組み込むこともできます (詳細については、<literal>SQLExceptionConverterFactory</literal> "
+"クラスの javadoc を参照してください)。標準的な <literal>JDBCException</literal> サブタイプは以下のとおりです。"
 
 #. Tag: para
 #: Transactions.xml:267
@@ -901,7 +1014,7 @@
 msgid ""
 "<literal>JDBCConnectionException</literal> - indicates an error with the "
 "underlying JDBC communication."
-msgstr ""
+msgstr "<literal>JDBCConnectionException</literal> - 基礎となる JDBC 通信でエラーが発生したことを示します。"
 
 #. Tag: para
 #: Transactions.xml:272
@@ -909,7 +1022,7 @@
 msgid ""
 "<literal>SQLGrammarException</literal> - indicates a grammar or syntax "
 "problem with the issued SQL."
-msgstr ""
+msgstr "<literal>SQLGrammarException</literal> - 発行された SQL で文法または構文のエラーが発生したことを示します。"
 
 #. Tag: para
 #: Transactions.xml:277
@@ -917,7 +1030,7 @@
 msgid ""
 "<literal>ConstraintViolationException</literal> - indicates some form of "
 "integrity constraint violation."
-msgstr ""
+msgstr "<literal>ConstraintViolationException</literal> - 何らかの整合性の制約違反が発生したことを示します。"
 
 #. Tag: para
 #: Transactions.xml:282
@@ -925,7 +1038,7 @@
 msgid ""
 "<literal>LockAcquisitionException</literal> - indicates an error acquiring a "
 "lock level necessary to perform the requested operation."
-msgstr ""
+msgstr "<literal>LockAcquisitionException</literal> - 要求した操作を実行するのに必要なロックレベルの取得エラーを示します。"
 
 #. Tag: para
 #: Transactions.xml:287
@@ -933,13 +1046,13 @@
 msgid ""
 "<literal>GenericJDBCException</literal> - a generic exception which did not "
 "fall into any of the other categories."
-msgstr ""
+msgstr "<literal>GenericJDBCException</literal> - 他のどのカテゴリにも属さない一般的な例外を示します。"
 
 #. Tag: title
 #: Transactions.xml:292
 #, no-c-format
 msgid "EXTENDED Persistence Context"
-msgstr ""
+msgstr "EXTENDED 永続コンテキスト"
 
 #. Tag: para
 #: Transactions.xml:293
@@ -950,7 +1063,7 @@
 "the persistence context type goes beyond the transaction life cycle. We "
 "should then understand what happens to operations made outside the scope of "
 "a transaction."
-msgstr ""
+msgstr "すべてのアプリケーション管理エンティティマネージャとそのように定義されたコンテナ管理永続コンテキストは <literal>EXTENDED</literal> になります。これは、永続コンテキストタイプがトランザクションライフサイクルよりも拡張されることを意味します。この場合、トランザクションのスコープ範囲外で行われた操作に何が起こるのかを理解する必要があります。"
 
 #. Tag: para
 #: Transactions.xml:296
@@ -967,12 +1080,14 @@
 "transaction: <literal>flush()</literal>, <literal>lock()</literal>, and "
 "update/delete queries."
 msgstr ""
+"<literal>EXTENDED</literal> 永続コンテキストでは、エンティティマネージャの読み取り専用操作 (<literal>find()</literal>、<literal>getReference()</literal>、"
+"<literal>refresh()</literal>、および読み取りクエリ) のすべてをトランザクションの外部で実行できます。一部の変更操作 (<literal>persist()</literal>、<literal><literal>merge()</literal></literal>、<literal>remove()</literal>) はトランザクションの外部で実行できますが、永続コンテキストがトランザクションに参加するまでキューに格納されます ()。一部の操作 (<literal>flush()</literal>、<literal>lock()</literal>、および更新/削除クエリ) はトランザクションの外部で呼び出すことができません。"
 
 #. Tag: title
 #: Transactions.xml:299
 #, no-c-format
 msgid "Container Managed Entity Manager"
-msgstr ""
+msgstr "コンテナ管理エンティティマネージャ"
 
 #. Tag: para
 #: Transactions.xml:300
@@ -983,7 +1098,7 @@
 "of the Stateful Session Bean. Plus if the entity manager is created outside "
 "a transaction, modifications operations (persist, merge, remove) are queued "
 "in the persistence context and not executed to the database."
-msgstr ""
+msgstr "コンテナ管理エンティティマネージャで EXTENDED 永続コンテキストを使用する場合は、永続コンテキストのライフサイクルがステートフルセッション Bean のライフサイクルにバインドされます。また、エンティティマネージャがトランザクションの外部で作成されると、変更操作 (永続化、マージ、削除) は永続コンテキストのキューに格納され、データベースに対して実行されません。"
 
 #. Tag: para
 #: Transactions.xml:303
@@ -993,7 +1108,7 @@
 "transaction is later called, the entity manager join the transaction. All "
 "queued operation will then be executed to synchronize the persistence "
 "context."
-msgstr ""
+msgstr "関連するステートフルセッション Bean またはトランザクションを開始するステートフルセッション Bean のメソッドが後で呼び出されると、エンティティマネージャがトランザクションに参加します。この結果、永続コンテキストを同期するためにキューに格納されたすべての操作が実行されます。"
 
 #. Tag: para
 #: Transactions.xml:306
@@ -1009,12 +1124,14 @@
 "look at JBoss Seam. Jboss Seam emphasizes the concept of conversation and "
 "entity manager lifecycle and bind EJB3 and JSF together."
 msgstr ""
+"これは、<literal>entitymanager-per-conversation</"
+"literal> パターンを実装するのに適しています。ステートフルセッション Bean は対話の実装を表します。中間的なすべての対話処理はトランザクションに関係しないメソッドで行われます。対話の終了は <literal>JTA</literal> トランザクションの内部で処理されます。したがって、キューに格納されたすべての操作は、データベースに対して実行され、コミットされます。アプリケーション内の対話の表記法に興味がある場合は、JBoss Seam を調べてください。Jboss Seam は対話とエンティティマネージャライフサイクルのコンセプトに基づき、EJB3 と JSF を統合します。"
 
 #. Tag: title
 #: Transactions.xml:309
 #, no-c-format
 msgid "Application Managed Entity Manager"
-msgstr ""
+msgstr "アプリケーション管理エンティティマネージャ"
 
 #. Tag: para
 #: Transactions.xml:310
@@ -1025,7 +1142,7 @@
 "automatically join the current transaction. If the entity manager is created "
 "outside a transaction, the entity manager will queue the modification "
 "operations. When"
-msgstr ""
+msgstr "アプリケーション管理エンティティマネージャは、常に <literal>EXTENDED</literal> となります。トランザクションの内部でエンティティマネージャを作成する場合、エンティティマネージャは自動的に現在のトランザクションに参加します。エンティティマネージャがトランザクションの外部で作成されると、エンティティマネージャは変更操作をキューに格納します。"
 
 #. Tag: para
 #: Transactions.xml:315
@@ -1033,7 +1150,7 @@
 msgid ""
 "<methodname>entityManager.joinTransaction()</methodname> is called when a "
 "JTA transaction is active for a <literal>JTA</literal> entity manager"
-msgstr ""
+msgstr "<methodname>entityManager.joinTransaction()</methodname> は、JTA トランザクションが <literal>JTA</literal> エンティティマネージャに対して有効である場合に呼び出されます。"
 
 #. Tag: para
 #: Transactions.xml:320
@@ -1041,7 +1158,7 @@
 msgid ""
 "<literal>entityManager.getTransaction().begin()</literal> is called for a "
 "<literal>RESOURCE_LOCAL</literal> entity manager"
-msgstr ""
+msgstr "<literal>entityManager.getTransaction().begin()</literal> は、<literal>RESOURCE_LOCAL</literal> エンティティマネージャに対して呼び出されます。"
 
 #. Tag: para
 #: Transactions.xml:325
@@ -1049,7 +1166,7 @@
 msgid ""
 "the entity manager join the transaction and all the queued operations will "
 "then be executed to synchronize the persistence context."
-msgstr ""
+msgstr "エンティティマネージャはトランザクションに参加し、永続コンテキストを同期するためにキューに格納されたすべての操作が実行されます。"
 
 #. Tag: para
 #: Transactions.xml:328
@@ -1058,12 +1175,14 @@
 "It is not legal to call <methodname>entityManager.joinTransaction()</"
 "methodname> if no JTA transaction is involved."
 msgstr ""
+"JTA トランザクションが関係しない場合に <methodname>entityManager.joinTransaction()</"
+"methodname> を呼び出すことは不正です。"
 
 #. Tag: title
 #: Transactions.xml:331
 #, no-c-format
 msgid "Optimistic concurrency control"
-msgstr ""
+msgstr "オプティミスティック並行性制御"
 
 #. Tag: para
 #: Transactions.xml:332
@@ -1077,13 +1196,13 @@
 "use cases we show are in the context of long application transactions but "
 "version checking also has the benefit of preventing lost updates in single "
 "database transactions."
-msgstr ""
+msgstr "高い並行性と高いスケーラビリティを実現する唯一の方法は、バージョン管理とともにオプティミスティック並行性制御を使用することです。バージョンの確認では、競合する更新を検出するために (および、更新の損失を防ぐために) バージョン番号またはタイムスタンプを使用します。Hibernate では、オプティミスティック並行性を使用するアプリケーションコードを記述するために 3 つの方法が用意されています。ここで示す使用例では、長いアプリケーショントランザクションを前提としていますが、バージョンの確認には、単一のデータベーストランザクションで更新の損失を防ぐ利点もあります。"
 
 #. Tag: title
 #: Transactions.xml:335
 #, no-c-format
 msgid "Application version checking"
-msgstr ""
+msgstr "アプリケーションバージョンの確認"
 
 #. Tag: para
 #: Transactions.xml:336
@@ -1097,6 +1216,8 @@
 "transaction isolation. This approach is the least efficient in terms of "
 "database access. It is the approach most similar to EJB2 entities:"
 msgstr ""
+"永続メカニズムをそんなに使用できない実装では、データベースとの各対話が新しい <literal>EntityManager</"
+"literal> で行われ、開発者はすべての永続インスタンスを処理する前にデータベースからインスタンスをリロードする必要があります。このアプローチにより、アプリケーショントランザクションの分離を保証するためにアプリケーションは強制的に独自のバージョン確認を実行するようになります。このアプローチはデータベースアクセスという点で最も非効率であり、EJB2 エンティティに最も似ています。"
 
 #. Tag: programlisting
 #: Transactions.xml:339
@@ -1115,6 +1236,18 @@
 "t.commit();\n"
 "em.close();"
 msgstr ""
+"// foo は以前のエンティティマネージャによりロードされたインスタンス\n"
+"em = factory.createEntityManager();\n"
+"EntityTransaction t = em.getTransaction();\n"
+"t.begin();\n"
+"int oldVersion = foo.getVersion();\n"
+"Foo dbFoo = em.find( foo.getClass(), foo.getKey() ); // load the current "
+"state\n"
+"if ( dbFoo.getVersion()!=foo.getVersion ) throw new StaleObjectStateException"
+"();\n"
+"dbFoo.setProperty(\"bar\");\n"
+"t.commit();\n"
+"em.close();"
 
 #. Tag: para
 #: Transactions.xml:340
@@ -1124,6 +1257,8 @@
 "literal>, and the entity manager will automatically increment it during "
 "flush if the entity is dirty."
 msgstr ""
+"<literal>version</literal> プロパティは、<literal>@Version</"
+"literal> を使用してマップされ、エンティティがダーティな場合はエンティティマネージが自動的に値をインクリメントします。"
 
 #. Tag: para
 #: Transactions.xml:343
@@ -1136,7 +1271,7 @@
 "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 ""
+msgstr "当然、低いデータ並行性の環境で稼働し、バージョン確認を必要としない場合は、このアプローチを使用してバージョン確認を省略できます。この場合、長いアプリケーショントランザクションで<emphasis></emphasis>「最後のコミットが優先される」ことがデフォルトになります。これにより、エラーメッセージが表示されなかったり、競合する変更をマージする機会が与えられずに更新が失われることがあるので、アプリケーションのユーザーが混乱する場合があることに注意してください。"
 
 #. Tag: para
 #: Transactions.xml:346
@@ -1147,13 +1282,13 @@
 "instances, but complete graphs of modified ojects have to be checked. "
 "Hibernate offers automatic version checking with either detached instances "
 "or an extended entity manager and persistence context as the design paradigm."
-msgstr ""
+msgstr "明らかなことは手動でのバージョン確認は非常に限られた状況でのみ現実的であり、ほとんどのアプリケーションでは現実的ではありません。多くの場合、単一のインスタンスだけでなく変更されたオブジェクトの完全なグラフも確認する必要があります。Hibernate は、設計パラダイムとして接続解除されたインスタンス、または拡張されたエンティティマネージャおよび永続コンテキストのいずれかを使用して自動的にバージョン確認を行います。"
 
 #. Tag: title
 #: Transactions.xml:349
 #, no-c-format
 msgid "Extended entity manager and automatic versioning"
-msgstr ""
+msgstr "拡張されたエンティティマネージャと自動バージョン管理"
 
 #. Tag: para
 #: Transactions.xml:350
@@ -1165,7 +1300,7 @@
 "developer to catch and handle this exception (common options are the "
 "opportunity for the user to merge his changes or to restart the business "
 "process with non-stale data)."
-msgstr ""
+msgstr "単一の永続コンテキストは、アプリケーショントランザクション全体で使用されます。エンティティマネージャはフラッシュ時にインスタンスバージョンを確認し、同時変更が検出されたら例外をスローします。この例外を捕捉し処理するのは開発者次第です (一般的な処理としては、ユーザーが変更内容をマージできるようにしたり、整合的なデータでビジネスプロセスを再開できるようにしたりすることなどがあります)。"
 
 #. Tag: para
 #: Transactions.xml:353
@@ -1176,6 +1311,8 @@
 "persistence context is flushed when executed in an active transaction (at "
 "worse at commit time)."
 msgstr ""
+"<literal>EXTENDED</literal> 永続コンテキストでは、アクティブなトランザクションの外部で行われたすべての操作はキューに格納されます。<literal>EXTENDED</literal> "
+"永続コンテキストは、アクティブなトランザクションでの実行時 (最悪でもコミット時) にフラッシュされます。"
 
 #. Tag: para
 #: Transactions.xml:356
@@ -1195,6 +1332,9 @@
 "is no performance impact. The following examples show the idiom in a non-"
 "managed environment:"
 msgstr ""
+"<literal>Entity Manager</literal> は、ユーザー対話の待機時に基礎となる "
+"JDBC 接続から切断されます。これは、アプリケーション管理拡張エンティティマネージャではトランザクションの完了時に自動的に行われます。また、これはコンテナ管理拡張エンティティマネージャを保持するステートフルセッション Bean (<literal>@PersistenceContext"
+"(EXTENDED)</literal> というアノテーションを持つ SFSB など) では透過的に行われます。このアプローチは、データベースアクセスの観点から最も効率的であす。アプリケーションではバージョン確認や接続解除されたインスタンスのマージについて心配する必要がなく、各データベーストランザクションでインスタンスをリロードする必要もありません。オープンおよびクローズする接続の数が気になるかもしれませんが、接続プロバイダは接続プールでなければならないことを思い出してください。したがって、パフォーマンスの影響はありません。以下に、管理されていない環境でのイディオムの例を示します。"
 
 #. Tag: programlisting
 #: Transactions.xml:359
@@ -1206,6 +1346,10 @@
 "foo.setProperty(\"bar\");\n"
 "em.getTransaction().commit();  // End tx, flush and check version, disconnect"
 msgstr ""
+"// foo は拡張エンティティマネージャによってロードされたインスタンス\n"
+"em.getTransaction.begin(); // データストアへの新しい接続が取得され tx が開始される\n"
+"foo.setProperty(\"bar\");\n"
+"em.getTransaction().commit();  // tx を終了、バージョンをフラッシュおよび確認、接続解除"
 
 #. Tag: para
 #: Transactions.xml:360
@@ -1218,6 +1362,8 @@
 "will not only flush and check versions, but also disconnects the entity "
 "manager from the JDBC connection and return the connection to the pool."
 msgstr ""
+"<literal>foo</literal> オブジェクトはロードされた永続コンテキストを認識します。<literal>getTransaction.begin();</"
+"literal> により、エンティティマネージャは新しい接続を取得し、永続コンテキストを再開します。メソッド <literal>getTransaction().commit()</literal> はバージョンをフラッシュし確認するだけでなく、 エンティティマネージャから JDBC 接続を解除し、接続をプールに返します。"
 
 #. Tag: para
 #: Transactions.xml:363
@@ -1230,7 +1376,7 @@
 "contains all loaded objects, we can probably use this strategy only for a "
 "few request/response cycles. This is indeed recommended, as the persistence "
 "context will soon also have stale data."
-msgstr ""
+msgstr "このパターンは、ユーザーの考えている時間に永続コンテキストが大きすぎて格納できず、永続コンテキストを格納する場所がわからない場合に問題となります。たとえば、<literal>HttpSession</literal> はできるだけ小さくすべきです。永続コンテキストは第一レベル (必須) のキャッシュであり、ロードされたすべてのオブジェクトを含むため、多くの場合、このアプローチは少数の要求/応答サイクルに対してのみ使用できます。ただし、永続コンテキストはすぐに不整合なデータを持つため、実際にはこのアプローチが推奨されます。"
 
 #. Tag: para
 #: Transactions.xml:366
@@ -1242,13 +1388,13 @@
 "separate tier) to store it in the <literal>HttpSession</literal>. In a non-"
 "managed, two-tiered environment the <literal>HttpSession</literal> might "
 "indeed be the right place to store it."
-msgstr ""
+msgstr "要求時に拡張エンティティマネージャをどこに格納するかは自由に決めることができます。これは、EJB3 コンテナの内部で上記で説明したステートフルセッション Bean を使用するだけで行えます。拡張エンティティマネージャを Web レイヤに転送し (または別のレイヤに対してシリアル化し)、<literal>HttpSession</literal> に格納しないでください。管理されていない 2 つのレイヤ環境では、<literal>HttpSession</literal> が適切な保管場所になることもあります。"
 
 #. Tag: title
 #: Transactions.xml:369
 #, no-c-format
 msgid "Detached objects and automatic versioning"
-msgstr ""
+msgstr "接続解除されたオブジェクトと自動バージョン管理"
 
 #. Tag: para
 #: Transactions.xml:370
@@ -1259,7 +1405,7 @@
 "each interaction with the database. The application manipulates the state of "
 "detached instances originally loaded in another persistence context and then "
 "merges the changes using <literal>EntityManager.merge()</literal>:"
-msgstr ""
+msgstr "このパラダイムでは、データストアとの各対話は新しい永続コンテキストで行われます。ただし、データベースとの各対話に対しては同じ永続インスタンスが再利用されます。アプリケーションは別の永続コンテキストに最初にロードされた接続解除されたインスタンスの状態を操作し、<literal>EntityManager.merge()</literal> を使用して変更をマージします。"
 
 #. Tag: programlisting
 #: Transactions.xml:373
@@ -1274,6 +1420,13 @@
 "entityManager.getTransaction().commit();\n"
 "entityManager.close();"
 msgstr ""
+"// foo は非拡張エンティティマネージャによりロードされたインスタンス\n"
+"foo.setProperty(\"bar\");\n"
+"entityManager = factory.createEntityManager();\n"
+"entityManager.getTransaction().begin();\n"
+"managedFoo = session.merge(foo); // foo を破棄し、今後は managedFoo を使用\n"
+"entityManager.getTransaction().commit();\n"
+"entityManager.close();"
 
 #. Tag: para
 #: Transactions.xml:374
@@ -1281,4 +1434,5 @@
 msgid ""
 "Again, the entity manager will check instance versions during flush, "
 "throwing an exception if conflicting updates occured."
-msgstr ""
+msgstr "ここでも再び、エンティティマネージャはフラッシュ時にインスタンスバージョンを確認し、更新の競合が発生したら例外をスローします。"
+

More information about the jboss-cvs-commits mailing list