[hibernate-commits] Hibernate SVN: r14131 -
core/trunk/documentation/manual/ja-JP/src/main/docbook/content.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Thu Oct 25 03:54:59 EDT 2007
Author: xhuang at jboss.com
Date: 2007-10-25 03:54:59 -0400 (Thu, 25 Oct 2007)
New Revision: 14131
Modified:
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/architecture.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/basic_mapping.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/batch.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/performance.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/query_hql.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/session_api.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/toolset_guide.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/transactions.xml
core/trunk/documentation/manual/ja-JP/src/main/docbook/content/tutorial.xml
Log:
match to latest English XML
Modified: core/trunk/documentation/manual/ja-JP/src/main/docbook/content/architecture.xml
===================================================================
--- core/trunk/documentation/manual/ja-JP/src/main/docbook/content/architecture.xml 2007-10-25 06:31:49 UTC (rev 14130)
+++ core/trunk/documentation/manual/ja-JP/src/main/docbook/content/architecture.xml 2007-10-25 07:54:59 UTC (rev 14131)
@@ -1,377 +1,377 @@
-<?xml version="1.0" encoding="UTF-8"?>>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
-
-<chapter id="architecture">
-
- <title>アーキテクチャ</title>
-
- <sect1 id="architecture-overview" revision="1">
- <title>概観</title>
-
- <para>
- Hibernateアーキテクチャの（非常に）高いレベルからのビュー：
- </para>
-
- <mediaobject>
- <imageobject role="fo">
- <imagedata fileref="../images/overview.svg" format="SVG" align="center"/>
- </imageobject>
- <imageobject role="html">
- <imagedata fileref="../images/overview.png" format="PNG" align="center"/>
- </imageobject>
- </mediaobject>
-
- <para>
- この図はHibernateが、アプリケーションに対して永続化サービス
- （と永続オブジェクト）を提供するために、データベースと設定データを使うことを
- 示しています。
- </para>
-
- <para>
- ここで実行時アーキテクチャのより詳細なビューをお見せしましょう。
- あいにく、Hibernateは柔軟であり、いろいろなアプローチをサポートしています。
- ここでは、2つの極端な例をお見せします。
- 「軽い」アーキテクチャでは、アプリケーションが自前のJDBCコネクションを用意し、
- アプリケーション自身がトランザクションを管理します。
- この方法は、Hibernate APIの最小限のサブセットを使います：
- </para>
-
- <mediaobject>
- <imageobject role="fo">
- <imagedata fileref="../images/lite.svg" format="SVG" align="center"/>
- </imageobject>
- <imageobject role="html">
- <imagedata fileref="../images/lite.png" format="PNG" align="center"/>
- </imageobject>
- </mediaobject>
-
- <para>
- 「重い」アーキテクチャは、アプリケーションから、その下に位置するJDBCやJTAのAPIを
- 取り払って抽象化し、その詳細の面倒をHibernateに見させます。
- </para>
-
- <mediaobject>
- <imageobject role="fo">
- <imagedata fileref="../images/full_cream.svg" format="SVG" align="center"/>
- </imageobject>
- <imageobject role="html">
- <imagedata fileref="../images/full_cream.png" format="PNG" align="center"/>
- </imageobject>
- </mediaobject>
-
- <para>
- 以下は、上の図に含まれるオブジェクトの定義です：
-
- <variablelist spacing="compact">
- <varlistentry>
- <term>SessionFactory (<literal>org.hibernate.SessionFactory</literal>)</term>
- <listitem>
- <para>
- 1つのデータベースに対するコンパイルされたマッピングの
- スレッドセーフな（更新不能の）キャッシュ。
- <literal>Session</literal> のファクトリであり、
- <literal>ConnectionProvider</literal> のクライアント。
- オプションとして、プロセスまたはクラスタレベルにおいて、
- トランザクション間で再利用可能なデータの（二次）キャッシュを持ちます。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Session (<literal>org.hibernate.Session</literal>)</term>
- <listitem>
- <para>
- アプリケーションと永続ストアとの対話を表す、
- シングルスレッドで短命のオブジェクト。
- JDBCコネクションをラップします。
- <literal>Transaction</literal> のファクトリです。
- 永続オブジェクトの必須の（一次）キャッシュを保持します。
- このキャッシュはオブジェクトグラフをナビゲーションする時や、
- 識別子でオブジェクトを検索する時に使われます。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Persistent objects と Collections</term>
- <listitem>
- <para>
- 永続化状態とビジネスメソッドを持つ、短命でシングルスレッドのオブジェクト。
- これは通常のJavaBeans/POJOのこともありますが、特徴的なことは、
- その時点での（ただ1つの） <literal>Session</literal> と関連していることです。
- <literal>Session</literal> がクローズされるとすぐに、
- それらは切り離されて他のアプリケーション層から自由に使うことができます。
- （例えばデータ・トランスファ・オブジェクトとして、
- プレゼンテーション層から、またはプレゼンテーション層へ直接使用できます。）
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Transient と detached な objects と Collections</term>
- <listitem>
- <para>
- 現時点では <literal>Session</literal> と関連していない、
- 永続クラスのインスタンス。
- すでにアプリケーション側でインスタンス化されていて、まだ永続化されていないか、
- クローズされた <literal>Session</literal> でインスタンス化されたかのどちらかです。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>Transaction (<literal>org.hibernate.Transaction</literal>)</term>
- <listitem>
- <para>
- (オプション)原子性を持つ作業単位(Unit of Work)を指定するために、アプリケーションが使用する、
- シングルスレッドで短命なオブジェクト。
- 下に位置するJDBC、JTA、CORBAトランザクションからアプリケーションを抽象化します。
- <literal>Session</literal> は、時には
- いくつかの <literal>Transaction</literal> をまたがるかもしれません。
- しかし、下の層のAPIを使うにせよ、 <literal>Transaction</literal> を使うにせよ、
- トランザクション境界を設定することは、決してオプションではありません！。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>ConnectionProvider (<literal>org.hibernate.connection.ConnectionProvider</literal>)</term>
- <listitem>
- <para>
- (オプション)JDBCコネクション（とそのプール）のファクトリ。
- 下の層に位置する <literal>Datasource</literal> や
- <literal>DriverManager</literal> からアプリケーションを抽象化します。
- アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>TransactionFactory (<literal>org.hibernate.TransactionFactory</literal>)</term>
- <listitem>
- <para>
- (オプション) <literal>Transaction</literal> インスタンスのファクトリ。
- アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><emphasis>Extension Interfaces</emphasis></term>
- <listitem>
- <para>
- Hibernateは、永続層の振る舞いをカスタマイズするために、
- 多くのオプション拡張インタフェースを用意しています。
- 詳細はAPIドキュメントを参照してください。
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
-
- <para>
- 「軽い」アーキテクチャでは、アプリケーションは直接JTAやJDBCと対話するために、
- <literal>Transaction</literal> や <literal>TransactionFactory</literal> や
- <literal>ConnectionProvider</literal> をバイパスします。
- </para>
- </sect1>
-
- <sect1 id="architecture-states" revision="1">
- <title>インスタンスの状態</title>
- <para>
- 永続クラスのインスタンスは、次の３つの異なる状態のどれかになります。
- それは、 <emphasis>永続コンテキスト</emphasis> によって決まります。
- Hibernateの <literal>Session</literal> オブジェクトが、永続コンテキストになります。
- </para>
-
- <variablelist spacing="compact">
- <varlistentry>
- <term>transient</term>
- <listitem>
- <para>
- この状態のインスタンスは、現在もそして過去においても、
- 永続コンテキストに関連づいていません。また、永続ID（主キーの値）を
- 持っていません。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>persistent</term>
- <listitem>
- <para>
- この状態のインスタンスは、その時点で永続コンテキストに関連づいています。
- また、永続ID（主キーの値）を持ち、
- たいていはデータベースに対応する行を持っているでしょう。
- 個々の永続コンテキストのなかでは、永続IDが
- JavaのID（オブジェクトのメモリ上の位置）と同じであることを
- Hibernateが <emphasis>保証</emphasis> します。
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>detached</term>
- <listitem>
- <para>
- この状態のインスタンスは、かつて永続コンテキストに関連づけられたが、
- そのコンテキストがクローズされたか、あるいは、
- 他のプロセスにそのインスタンスがシリアライズされたかです。
- このインスタンスは、永続IDを持ち、たいていはデータベースに
- 対応する行を持っているでしょう。分離インスタンスに対しては、
- 永続IDとJavaのIDとの関連は、Hibernateが保証しません。
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </sect1>
-
- <sect1 id="architecture-jmx" revision="1">
- <title>JMXとの統合</title>
-
- <para>
- JMXはJavaコンポーネント管理のJ2EE標準です。
- JMX標準サービスを通して、Hibernateは管理されます。
- ディストリビューションの中に <literal>org.hibernate.jmx.HibernateService</literal> という
- MBean実装を用意しています。
- </para>
-
- <para>
- JBoss アプリケーションサーバー上にHibernateをJMXサービスとしてデプロイする方法の例としては、
- JBoss ユーザガイドを参照してください。 JBoss アプリケーションサーバーにおいて、
- JMXを使ってデプロイすると、次のメリットが得られます。
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>セッション管理:</emphasis> Hibernateの <literal>Session</literal> のライフサイクルは、
- 自動的にJTAトランザクションのスコープに結びつけられます。これは、もはや手動で
- <literal>Session</literal> をオープンしたり、クローズしたりする必要がないことを意味します。
- これは、JBoss EJB インターセプタの仕事になります。
- また、コードのどこでトランザクション境界を設定するかについて、
- もはや悩む必要がありません（もちろん移植可能な永続層を書かかなくていいのならば、
- オプションのHibernateの <literal>Transaction</literal> を使用してください。）
- <literal>Session</literal> にアクセスするためには、 <literal>HibernateContext</literal> を
- コールしてください。
- </para>
- </listitem>
- <listitem>
- <para>
- <emphasis>HAR デプロイ:</emphasis> 通常、(EAR または SAR ファイルにある）JBoss サービス
- デプロイメントディスクリプタを使って、Hibernate JMX サービスをデプロイします。
- それは、Hibernateの <literal>SessionFactory</literal> の全ての一般的な設定オプションを
- サポートします。しかし依然としてデプロイメントディスクリプタのなかにすべてのマッピングファイルの
- 名前を挙げる必要があります。
- もし、オプションのHARデプロイメントを使うことを決めたなら、
- JBossは自動的にHARファイルのなかの全てのマッピングファイルを検出します。
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- これらのオプションについての詳細な情報は、JBossアプリケーションサーバユーザガイドを
- 参考にしてください。
- </para>
-
- <para>
- JMXサービスとして利用可能な他の機能に、Hibernate実行時統計情報があります。
- <xref linkend="configuration-optional-statistics"/> を見てください。
- </para>
- </sect1>
-
- <sect1 id="architecture-jca" revision="1">
- <title>JCA サポート</title>
- <para>
- Hibernate は JCA コネクタとしても設定できます。詳細については、Webサイトを見てください。
- Hibernate JCA サポートは、今のところ実験段階として考えられていることに注意してください。
- </para>
- </sect1>
-
- <sect1 id="architecture-current-session" revision="2">
- <title>コンテキスト上のセッション</title>
- <para>
- Hibernate を使ったアプリケーションは、ほとんど、なんらかの形で"コンテキスト上の"セッションが必要になります。
- 「コンテキスト上のセッション」は、特定のコンテキストのスコープのなかで有効なセッションのことです。
- しかし、通常アプリケーションごとにコンテキストを構成するものの定義は異なります。
- しかも、異なる複数のコンテキストは、現時点に対して異なるスコープを定義します。
- バージョン3.0より前の Hibernate では、自作の <literal>ThreadLocal</literal> ベースの「コンテキスト上のセッション」を
- 利用するか、 <literal>HibernateUtil</literal> のようなヘルパークラスを利用するか、
- proxy/interception ベースの「コンテキスト上のセッション」を提供する
- （Spring や Pico のような）サードパーティのフレームワークを利用するかのいずれかでした。
- </para>
-
- <para>
- バージョン 3.0.1 から、Hibernate には <literal>SessionFactory.getCurrentSession()</literal> が
- 加わりました。 これは、 <literal>JTA</literal> トランザクションの使用を前提にしています。
- <literal>JTA</literal> トランザクションは、現在のセッションのスコープとコンテキストの両方を定義します。
- Hibernate チームは、次のことを主張します。
- 巨大なスタンドアロンの <literal>JTA TransactionManager</literal> 実装が成熟したら、
- <literal>J2EE</literal> コンテナ上にデプロイされるかどうかにかかわらず、
- ほとんどの（すべてとは言わないが）アプリケーションが、
- <literal>JTA</literal> トランザクション管理を使用すべきであると。
- この考えに基づくと、 <literal>JTA</literal> ベースの「コンテキスト上のセッション」を
- 使うしかないでしょう。
- </para>
-
- <para>
- しかし、バージョン 3.1 からは、 <literal>SessionFactory.getCurrentSession()</literal> の後の処理が、
- プラガブルになりました。
- これを受けて、現在のセッションを定義するスコープとコンテキストのプラガビリティを可能にするために、
- 新しい拡張インタフェース ( <literal>org.hibernate.context.CurrentSessionContext</literal> ) と
- 新しい構成パラメータ ( <literal>hibernate.current_session_context_class</literal> ) が追加されました。
- </para>
-
- <para>
- <literal>org.hibernate.context.CurrentSessionContext</literal> インタフェースの規約についての
- 詳細な内容は Javadoc を参照してください。
- それには、 <literal>currentSession()</literal> という1つのメソッドが定義されており、
- その実装は、現在の「コンテキスト上のセッション」を追跡することに責任を持ちます。
- そのまま使えるように、Hibernateはこのインタフェースの実装を2つ提供しています。
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- <literal>org.hibernate.context.JTASessionContext</literal> -
- <literal>JTA</literal> トランザクションによって、現在のセッションが追跡され、
- スコープを決められます。この処理は、古いJTAだけのアプローチとまったく同じです。
- 詳細はJavadocを参照してください。
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>org.hibernate.context.ThreadLocalSessionContext</literal> -
- スレッドの実行によって、現在のセッションが追跡されます。
- 詳細はJavadocを参照してください。
- </para>
- </listitem>
- <listitem>
- <para>
- <literal>org.hibernate.context.ManagedSessionContext</literal> -
- スレッドの実行によって、現在のセッションが追跡されます。
- しかし、このクラスのstaticメソッドで <literal>Session</literal> インスタンスを
- バインド/アンバインドする責任はあなたにあります。
- これは決して <literal>Session</literal> をオープン、フラッシュ、クローズしません。
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- 始めの2つの実装は、"1セッション - 1データベーストランザクション" プログラミングモデルを提供します。
- これは <emphasis>リクエストごとのセッション（session-per-request）</emphasis> としても知られており、使われています。
- Hibernate セッションの開始と終了は、データベーストランザクションの期間で決まります。
- JTAを使わない普通のJSEで、プログラム上のトランザクション境界設定を行うなら、
- コードから基礎のトランザクションシステムを隠蔽するために、
- Hibernate <literal>Transaction</literal> APIを使うとよいでしょう。
- JTAを使うなら、トランザクションの境界設定には、JTAインターフェイスを使ってください。
- CMTをサポートするEJBコンテナで実行するつもりなら、トランザクション境界は宣言的に定義できるため、
- コード上でトランザクションやセッションの境界を設定する必要はありません。
- さらに詳細な情報やコードの例は、 <xref linkend="transactions"/> を参照してください。
- </para>
-
- <para>
- <literal>hibernate.current_session_context_class</literal> 設定パラメータは、
- <literal>org.hibernate.context.CurrentSessionContext</literal> のどの実装を使うかを指定します。
- 下位互換性のため、このパラメータが設定されず
- <literal>org.hibernate.transaction.TransactionManagerLookup</literal> が設定されていた場合、
- Hibernateは <literal>org.hibernate.context.JTASessionContext</literal> を使うことに注意してください。
- 通常このパラメータの値には、3つの実装の中から使用する実装クラスの名前を直接指定します。
- しかし、"jta", "thread", "managed"というそれぞれの省略名も用意されています。
- </para>
-
- </sect1>
-
-</chapter>
-
+
+<chapter id="architecture">
+
+ <title>アーキテクチャ</title>
+
+ <sect1 id="architecture-overview" revision="1">
+ <title>概観</title>
+
+ <para>
+ Hibernateアーキテクチャの（非常に）高いレベルからのビュー：
+ </para>
+
+ <mediaobject>
+ <imageobject role="fo">
+ <imagedata fileref="../images/overview.svg" format="SVG" align="center"/>
+ </imageobject>
+ <imageobject role="html">
+ <imagedata fileref="../images/overview.png" format="PNG" align="center"/>
+ </imageobject>
+ </mediaobject>
+
+ <para>
+ この図はHibernateが、アプリケーションに対して永続化サービス
+ （と永続オブジェクト）を提供するために、データベースと設定データを使うことを
+ 示しています。
+ </para>
+
+ <para>
+ ここで実行時アーキテクチャのより詳細なビューをお見せしましょう。
+ あいにく、Hibernateは柔軟であり、いろいろなアプローチをサポートしています。
+ ここでは、2つの極端な例をお見せします。
+ 「軽い」アーキテクチャでは、アプリケーションが自前のJDBCコネクションを用意し、
+ アプリケーション自身がトランザクションを管理します。
+ この方法は、Hibernate APIの最小限のサブセットを使います：
+ </para>
+
+ <mediaobject>
+ <imageobject role="fo">
+ <imagedata fileref="../images/lite.svg" format="SVG" align="center"/>
+ </imageobject>
+ <imageobject role="html">
+ <imagedata fileref="../images/lite.png" format="PNG" align="center"/>
+ </imageobject>
+ </mediaobject>
+
+ <para>
+ 「重い」アーキテクチャは、アプリケーションから、その下に位置するJDBCやJTAのAPIを
+ 取り払って抽象化し、その詳細の面倒をHibernateに見させます。
+ </para>
+
+ <mediaobject>
+ <imageobject role="fo">
+ <imagedata fileref="../images/full_cream.svg" format="SVG" align="center"/>
+ </imageobject>
+ <imageobject role="html">
+ <imagedata fileref="../images/full_cream.png" format="PNG" align="center"/>
+ </imageobject>
+ </mediaobject>
+
+ <para>
+ 以下は、上の図に含まれるオブジェクトの定義です：
+
+ <variablelist spacing="compact">
+ <varlistentry>
+ <term>SessionFactory (<literal>org.hibernate.SessionFactory</literal>)</term>
+ <listitem>
+ <para>
+ 1つのデータベースに対するコンパイルされたマッピングの
+ スレッドセーフな（更新不能の）キャッシュ。
+ <literal>Session</literal> のファクトリであり、
+ <literal>ConnectionProvider</literal> のクライアント。
+ オプションとして、プロセスまたはクラスタレベルにおいて、
+ トランザクション間で再利用可能なデータの（二次）キャッシュを持ちます。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Session (<literal>org.hibernate.Session</literal>)</term>
+ <listitem>
+ <para>
+ アプリケーションと永続ストアとの対話を表す、
+ シングルスレッドで短命のオブジェクト。
+ JDBCコネクションをラップします。
+ <literal>Transaction</literal> のファクトリです。
+ 永続オブジェクトの必須の（一次）キャッシュを保持します。
+ このキャッシュはオブジェクトグラフをナビゲーションする時や、
+ 識別子でオブジェクトを検索する時に使われます。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Persistent objects と Collections</term>
+ <listitem>
+ <para>
+ 永続化状態とビジネスメソッドを持つ、短命でシングルスレッドのオブジェクト。
+ これは通常のJavaBeans/POJOのこともありますが、特徴的なことは、
+ その時点での（ただ1つの） <literal>Session</literal> と関連していることです。
+ <literal>Session</literal> がクローズされるとすぐに、
+ それらは切り離されて他のアプリケーション層から自由に使うことができます。
+ （例えばデータ・トランスファ・オブジェクトとして、
+ プレゼンテーション層から、またはプレゼンテーション層へ直接使用できます。）
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Transient と detached な objects と Collections</term>
+ <listitem>
+ <para>
+ 現時点では <literal>Session</literal> と関連していない、
+ 永続クラスのインスタンス。
+ すでにアプリケーション側でインスタンス化されていて、まだ永続化されていないか、
+ クローズされた <literal>Session</literal> でインスタンス化されたかのどちらかです。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Transaction (<literal>org.hibernate.Transaction</literal>)</term>
+ <listitem>
+ <para>
+ (オプション)原子性を持つ作業単位(Unit of Work)を指定するために、アプリケーションが使用する、
+ シングルスレッドで短命なオブジェクト。
+ 下に位置するJDBC、JTA、CORBAトランザクションからアプリケーションを抽象化します。
+ <literal>Session</literal> は、時には
+ いくつかの <literal>Transaction</literal> をまたがるかもしれません。
+ しかし、下の層のAPIを使うにせよ、 <literal>Transaction</literal> を使うにせよ、
+ トランザクション境界を設定することは、決してオプションではありません！。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ConnectionProvider (<literal>org.hibernate.connection.ConnectionProvider</literal>)</term>
+ <listitem>
+ <para>
+ (オプション)JDBCコネクション（とそのプール）のファクトリ。
+ 下の層に位置する <literal>Datasource</literal> や
+ <literal>DriverManager</literal> からアプリケーションを抽象化します。
+ アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>TransactionFactory (<literal>org.hibernate.TransactionFactory</literal>)</term>
+ <listitem>
+ <para>
+ (オプション) <literal>Transaction</literal> インスタンスのファクトリ。
+ アプリケーションには公開されませんが、開発者が継承または実装することは可能です。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><emphasis>Extension Interfaces</emphasis></term>
+ <listitem>
+ <para>
+ Hibernateは、永続層の振る舞いをカスタマイズするために、
+ 多くのオプション拡張インタフェースを用意しています。
+ 詳細はAPIドキュメントを参照してください。
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <para>
+ 「軽い」アーキテクチャでは、アプリケーションは直接JTAやJDBCと対話するために、
+ <literal>Transaction</literal> や <literal>TransactionFactory</literal> や
+ <literal>ConnectionProvider</literal> をバイパスします。
+ </para>
+ </sect1>
+
+ <sect1 id="architecture-states" revision="1">
+ <title>インスタンスの状態</title>
+ <para>
+ 永続クラスのインスタンスは、次の３つの異なる状態のどれかになります。
+ それは、 <emphasis>永続コンテキスト</emphasis> によって決まります。
+ Hibernateの <literal>Session</literal> オブジェクトが、永続コンテキストになります。
+ </para>
+
+ <variablelist spacing="compact">
+ <varlistentry>
+ <term>transient</term>
+ <listitem>
+ <para>
+ この状態のインスタンスは、現在もそして過去においても、
+ 永続コンテキストに関連づいていません。また、永続ID（主キーの値）を
+ 持っていません。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>persistent</term>
+ <listitem>
+ <para>
+ この状態のインスタンスは、その時点で永続コンテキストに関連づいています。
+ また、永続ID（主キーの値）を持ち、
+ たいていはデータベースに対応する行を持っているでしょう。
+ 個々の永続コンテキストのなかでは、永続IDが
+ JavaのID（オブジェクトのメモリ上の位置）と同じであることを
+ Hibernateが <emphasis>保証</emphasis> します。
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>detached</term>
+ <listitem>
+ <para>
+ この状態のインスタンスは、かつて永続コンテキストに関連づけられたが、
+ そのコンテキストがクローズされたか、あるいは、
+ 他のプロセスにそのインスタンスがシリアライズされたかです。
+ このインスタンスは、永続IDを持ち、たいていはデータベースに
+ 対応する行を持っているでしょう。分離インスタンスに対しては、
+ 永続IDとJavaのIDとの関連は、Hibernateが保証しません。
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect1>
+
+ <sect1 id="architecture-jmx" revision="1">
+ <title>JMXとの統合</title>
+
+ <para>
+ JMXはJavaコンポーネント管理のJ2EE標準です。
+ JMX標準サービスを通して、Hibernateは管理されます。
+ ディストリビューションの中に <literal>org.hibernate.jmx.HibernateService</literal> という
+ MBean実装を用意しています。
+ </para>
+
+ <para>
+ JBoss アプリケーションサーバー上にHibernateをJMXサービスとしてデプロイする方法の例としては、
+ JBoss ユーザガイドを参照してください。 JBoss アプリケーションサーバーにおいて、
+ JMXを使ってデプロイすると、次のメリットが得られます。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>セッション管理:</emphasis> Hibernateの <literal>Session</literal> のライフサイクルは、
+ 自動的にJTAトランザクションのスコープに結びつけられます。これは、もはや手動で
+ <literal>Session</literal> をオープンしたり、クローズしたりする必要がないことを意味します。
+ これは、JBoss EJB インターセプタの仕事になります。
+ また、コードのどこでトランザクション境界を設定するかについて、
+ もはや悩む必要がありません（もちろん移植可能な永続層を書かかなくていいのならば、
+ オプションのHibernateの <literal>Transaction</literal> を使用してください。）
+ <literal>Session</literal> にアクセスするためには、 <literal>HibernateContext</literal> を
+ コールしてください。
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis>HAR デプロイ:</emphasis> 通常、(EAR または SAR ファイルにある）JBoss サービス
+ デプロイメントディスクリプタを使って、Hibernate JMX サービスをデプロイします。
+ それは、Hibernateの <literal>SessionFactory</literal> の全ての一般的な設定オプションを
+ サポートします。しかし依然としてデプロイメントディスクリプタのなかにすべてのマッピングファイルの
+ 名前を挙げる必要があります。
+ もし、オプションのHARデプロイメントを使うことを決めたなら、
+ JBossは自動的にHARファイルのなかの全てのマッピングファイルを検出します。
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ これらのオプションについての詳細な情報は、JBossアプリケーションサーバユーザガイドを
+ 参考にしてください。
+ </para>
+
+ <para>
+ JMXサービスとして利用可能な他の機能に、Hibernate実行時統計情報があります。
+ <xref linkend="configuration-optional-statistics"/> を見てください。
+ </para>
+ </sect1>
+
+ <sect1 id="architecture-jca" revision="1">
+ <title>JCA サポート</title>
+ <para>
+ Hibernate は JCA コネクタとしても設定できます。詳細については、Webサイトを見てください。
+ Hibernate JCA サポートは、今のところ実験段階として考えられていることに注意してください。
+ </para>
+ </sect1>
+
+ <sect1 id="architecture-current-session" revision="2">
+ <title>コンテキスト上のセッション</title>
+ <para>
+ Hibernate を使ったアプリケーションは、ほとんど、なんらかの形で"コンテキスト上の"セッションが必要になります。
+ 「コンテキスト上のセッション」は、特定のコンテキストのスコープのなかで有効なセッションのことです。
+ しかし、通常アプリケーションごとにコンテキストを構成するものの定義は異なります。
+ しかも、異なる複数のコンテキストは、現時点に対して異なるスコープを定義します。
+ バージョン3.0より前の Hibernate では、自作の <literal>ThreadLocal</literal> ベースの「コンテキスト上のセッション」を
+ 利用するか、 <literal>HibernateUtil</literal> のようなヘルパークラスを利用するか、
+ proxy/interception ベースの「コンテキスト上のセッション」を提供する
+ （Spring や Pico のような）サードパーティのフレームワークを利用するかのいずれかでした。
+ </para>
+
+ <para>
+ バージョン 3.0.1 から、Hibernate には <literal>SessionFactory.getCurrentSession()</literal> が
+ 加わりました。 これは、 <literal>JTA</literal> トランザクションの使用を前提にしています。
+ <literal>JTA</literal> トランザクションは、現在のセッションのスコープとコンテキストの両方を定義します。
+ Hibernate チームは、次のことを主張します。
+ 巨大なスタンドアロンの <literal>JTA TransactionManager</literal> 実装が成熟したら、
+ <literal>J2EE</literal> コンテナ上にデプロイされるかどうかにかかわらず、
+ ほとんどの（すべてとは言わないが）アプリケーションが、
+ <literal>JTA</literal> トランザクション管理を使用すべきであると。
+ この考えに基づくと、 <literal>JTA</literal> ベースの「コンテキスト上のセッション」を
+ 使うしかないでしょう。
+ </para>
+
+ <para>
+ しかし、バージョン 3.1 からは、 <literal>SessionFactory.getCurrentSession()</literal> の後の処理が、
+ プラガブルになりました。
+ これを受けて、現在のセッションを定義するスコープとコンテキストのプラガビリティを可能にするために、
+ 新しい拡張インタフェース ( <literal>org.hibernate.context.CurrentSessionContext</literal> ) と
+ 新しい構成パラメータ ( <literal>hibernate.current_session_context_class</literal> ) が追加されました。
+ </para>
+
+ <para>
+ <literal>org.hibernate.context.CurrentSessionContext</literal> インタフェースの規約についての
+ 詳細な内容は Javadoc を参照してください。
+ それには、 <literal>currentSession()</literal> という1つのメソッドが定義されており、
+ その実装は、現在の「コンテキスト上のセッション」を追跡することに責任を持ちます。
+ そのまま使えるように、Hibernateはこのインタフェースの実装を2つ提供しています。
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <literal>org.hibernate.context.JTASessionContext</literal> -
+ <literal>JTA</literal> トランザクションによって、現在のセッションが追跡され、
+ スコープを決められます。この処理は、古いJTAだけのアプローチとまったく同じです。
+ 詳細はJavadocを参照してください。
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>org.hibernate.context.ThreadLocalSessionContext</literal> -
+ スレッドの実行によって、現在のセッションが追跡されます。
+ 詳細はJavadocを参照してください。
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>org.hibernate.context.ManagedSessionContext</literal> -
+ スレッドの実行によって、現在のセッションが追跡されます。
+ しかし、このクラスのstaticメソッドで <literal>Session</literal> インスタンスを
+ バインド/アンバインドする責任はあなたにあります。
+ これは決して <literal>Session</literal> をオープン、フラッシュ、クローズしません。
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ 始めの2つの実装は、"1セッション - 1データベーストランザクション" プログラミングモデルを提供します。
+ これは <emphasis>リクエストごとのセッション（session-per-request）</emphasis> としても知られており、使われています。
+ Hibernate セッションの開始と終了は、データベーストランザクションの期間で決まります。
+ JTAを使わない普通のJSEで、プログラム上のトランザクション境界設定を行うなら、
+ コードから基礎のトランザクションシステムを隠蔽するために、
+ Hibernate <literal>Transaction</literal> APIを使うとよいでしょう。
+ JTAを使うなら、トランザクションの境界設定には、JTAインターフェイスを使ってください。
+ CMTをサポートするEJBコンテナで実行するつもりなら、トランザクション境界は宣言的に定義できるため、
+ コード上でトランザクションやセッションの境界を設定する必要はありません。
+ さらに詳細な情報やコードの例は、 <xref linkend="transactions"/> を参照してください。
+ </para>
+
+ <para>
+ <literal>hibernate.current_session_context_class</literal> 設定パラメータは、
+ <literal>org.hibernate.context.CurrentSessionContext</literal> のどの実装を使うかを指定します。
+ 下位互換性のため、このパラメータが設定されず
+ <literal>org.hibernate.transaction.TransactionManagerLookup</literal> が設定されていた場合、
+ Hibernateは <literal>org.hibernate.context.JTASessionContext</literal> を使うことに注意してください。
+ 通常このパラメータの値には、3つの実装の中から使用する実装クラスの名前を直接指定します。
+ しかし、"jta", "thread", "managed"というそれぞれの省略名も用意されています。
+ </para>
+
+ </sect1>
+
+</chapter>
+
Modified: core/trunk/documentation/manual/ja-JP/src/main/docbook/content/basic_mapping.xml
===================================================================
--- core/trunk/documentation/manual/ja-JP/src/main/docbook/content/basic_mapping.xml 2007-10-25 06:31:49 UTC (rev 14130)
+++ core/trunk/documentation/manual/ja-JP/src/main/docbook/content/basic_mapping.xml 2007-10-25 07:54:59 UTC (rev 14131)
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<chapter id="mapping">
<title>基本的なO/Rマッピング</title>
@@ -801,6 +801,20 @@
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><literal>sequence-identity</literal></term>
+ <listitem>
+ <para>
+ a specialized sequence generation strategy which utilizes a
+ database sequence for the actual value generation, but combines
+ this with JDBC3 getGeneratedKeys to actually return the generated
+ identifier value as part of the insert statement execution. This
+ strategy is only known to be supported on Oracle 10g drivers
+ targetted for JDK 1.4. Note comments on these insert statements
+ are disabled due to a bug in the Oracle drivers.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</para>
@@ -918,6 +932,173 @@
</sect3>
</sect2>
+
+ <sect2 id="mapping-declaration-id-enhanced">
+ <title>Enhanced identifier generators</title>
+
+ <para>
+ Starting with release 3.2.3, there are 2 new generators which represent a re-thinking of 2 different
+ aspects of identifier generation. The first aspect is database portability; the second is optimization
+ (not having to query the database for every request for a new identifier value). These two new
+ generators are intended to take the place of some of the named generators described above (starting
+ in 3.3.x); however, they are included in the current releases and can be referenced by FQN.
+ </para>
+
+ <para>
+ The first of these new generators is <literal>org.hibernate.id.enhanced.SequenceStyleGenerator</literal>
+ which is intended firstly as a replacement for the <literal>sequence</literal> generator and secondly as
+ a better portability generator than <literal>native</literal> (because <literal>native</literal>
+ (generally) chooses between <literal>identity</literal> and <literal>sequence</literal> which have
+ largely different semantics which can cause subtle isssues in applications eyeing portability).
+ <literal>org.hibernate.id.enhanced.SequenceStyleGenerator</literal> however achieves portability in
+ a different manner. It chooses between using a table or a sequence in the database to store its
+ incrementing values depending on the capabilities of the dialect being used. The difference between this
+ and <literal>native</literal> is that table-based and sequence-based storage have the same exact
+ semantic (in fact sequences are exactly what Hibernate tries to emmulate with its table-based
+ generators). This generator has a number of configuration parameters:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>sequence_name</literal> (optional, defaults to <literal>hibernate_sequence</literal>):
+ The name of the sequence (or table) to be used.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>initial_value</literal> (optional, defaults to <literal>1</literal>): The initial
+ value to be retrieved from the sequence/table. In sequence creation terms, this is analogous
+ to the clause typical named "STARTS WITH".
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>increment_size</literal> (optional, defaults to <literal>1</literal>): The value by
+ which subsequent calls to the sequence/table should differ. In sequence creation terms, this
+ is analogous to the clause typical named "INCREMENT BY".
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>force_table_use</literal> (optional, defaults to <literal>false</literal>): Should
+ we force the use of a table as the backing structure even though the dialect might support
+ sequence?
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>value_column</literal> (optional, defaults to <literal>next_val</literal>): Only
+ relevant for table structures! The name of the column on the table which is used to
+ hold the value.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>optimizer</literal> (optional, defaults to <literal>none</literal>):
+ See <xref linkend="mapping-declaration-id-enhanced-optimizers"/>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ The second of these new generators is <literal>org.hibernate.id.enhanced.TableGenerator</literal> which
+ is intended firstly as a replacement for the <literal>table</literal> generator (although it actually
+ functions much more like <literal>org.hibernate.id.MultipleHiLoPerTableGenerator</literal>) and secondly
+ as a re-implementation of <literal>org.hibernate.id.MultipleHiLoPerTableGenerator</literal> utilizing the
+ notion of pluggable optimiziers. Essentially this generator defines a table capable of holding
+ a number of different increment values simultaneously by using multiple distinctly keyed rows. This
+ generator has a number of configuration parameters:
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>table_name</literal> (optional, defaults to <literal>hibernate_sequences</literal>):
+ The name of the table to be used.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>value_column_name</literal> (optional, defaults to <literal>next_val</literal>):
+ The name of the column on the table which is used to hold the value.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_column_name</literal> (optional, defaults to <literal>sequence_name</literal>):
+ The name of the column on the table which is used to hold the "segement key". This is the
+ value which distinctly identifies which increment value to use.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_value</literal> (optional, defaults to <literal>default</literal>):
+ The "segment key" value for the segment from which we want to pull increment values for
+ this generator.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>segment_value_length</literal> (optional, defaults to <literal>255</literal>):
+ Used for schema generation; the column size to create this segment key column.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>initial_value</literal> (optional, defaults to <literal>1</literal>):
+ The initial value to be retrieved from the table.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>increment_size</literal> (optional, defaults to <literal>1</literal>):
+ The value by which subsequent calls to the table should differ.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>optimizer</literal> (optional, defaults to <literal></literal>):
+ See <xref linkend="mapping-declaration-id-enhanced-optimizers"/>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
+ <sect2 id="mapping-declaration-id-enhanced-optimizers">
+ <title>Identifier generator optimization</title>
+ <para>
+ For identifier generators which store values in the database, it is inefficient for them to hit the
+ database on each and every call to generate a new identifier value. Instead, you'd ideally want to
+ group a bunch of them in memory and only hit the database when you have exhausted your in-memory
+ value group. This is the role of the pluggable optimizers. Currently only the two enhanced generators
+ (<xref linkend="mapping-declaration-id-enhanced"/> support this notion.
+ <itemizedlist spacing="compact">
+ <listitem>
+ <para>
+ <literal>none</literal> (generally this is the default if no optimizer was specified): This
+ says to not perform any optimizations, and hit the database each and every request.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>hilo</literal>: applies a hi/lo algorithm around the database retrieved values. The
+ values from the database for this optimizer are expected to be sequential. The values
+ retrieved from the database structure for this optimizer indicates the "group number"; the
+ <literal>increment_size</literal> is multiplied by that value in memory to define a group
+ "hi value".
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <literal>pooled</literal>: like was discussed for <literal>hilo</literal>, this optimizers
+ attempts to minimize the number of hits to the database. Here, however, we simply store
+ the starting value for the "next group" into the database structure rather than a sequential
+ value in combination with an in-memory grouping algorithm. <literal>increment_size</literal>
+ here refers to the values coming from the database.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
<sect2 id="mapping-declaration-compositeid" revision="3">
<title>composite-id</title>
Modified: core/trunk/documentation/manual/ja-JP/src/main/docbook/content/batch.xml
===================================================================
--- core/trunk/documentation/manual/ja-JP/src/main/docbook/content/batch.xml 2007-10-25 06:31:49 UTC (rev 14130)
+++ core/trunk/documentation/manual/ja-JP/src/main/docbook/content/batch.xml 2007-10-25 07:54:59 UTC (rev 14131)
@@ -1,388 +1,392 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
-
-<chapter id="batch">
- <title>バッチ処理</title>
-
- <para>
- Hibernateを使ってデータベースに100,000行を挿入する愚直な方法は、このようなものです：
- </para>
-
-<programlisting><![CDATA[Session session = sessionFactory.openSession();
-Transaction tx = session.beginTransaction();
-for ( int i=0; i<100000; i++ ) {
- Customer customer = new Customer(.....);
- session.save(customer);
-}
-tx.commit();
-session.close();]]></programlisting>
-
- <para>
- これは50,000番目の行のあたりで <literal>OutOfMemoryException</literal> で失敗するでしょう。
- Hibernateがセッションレベルキャッシュで、
- 新しく挿入されたすべての <literal>Customer</literal>
- インスタンスをキャッシュするからです。
- </para>
-
- <para>
- この章では、この問題を回避する方法を紹介します。
- しかしバッチ処理をするなら、JDBCバッチが使用可能であることが非常に重要です。
- そうでなければ手頃なパフォーマンスが得られません。
- JDBCバッチサイズを手頃な数値（例えば、10から50）に設定してください：
- </para>
-
-<programlisting><![CDATA[hibernate.jdbc.batch_size 20]]></programlisting>
-
- <para>
- また二次キャッシュが全く効かないプロセスで、
- このような作業をしたいと思うかもしれません：
- </para>
-
-<programlisting><![CDATA[hibernate.cache.use_second_level_cache false]]></programlisting>
-
- <para>
- しかし、これは絶対に必要というわけではありません。
- なぜなら明示的に <literal>CacheMode</literal> を設定して、
- 二次キャッシュとの相互作用を無効にすることができるからです。
-
- </para>
-
- <sect1 id="batch-inserts">
- <title>バッチ挿入</title>
-
- <para>
- 新しいオブジェクトを永続化するとき、一次キャッシュのサイズを制限するため、
- セッションを <literal>flush()</literal> して <literal>clear()</literal>
- しなければなりません。
- </para>
-
-<programlisting><![CDATA[Session session = sessionFactory.openSession();
-Transaction tx = session.beginTransaction();
-
-for ( int i=0; i<100000; i++ ) {
- Customer customer = new Customer(.....);
- session.save(customer);
- if ( i % 20 == 0 ) { //20, same as the JDBC batch size
- //flush a batch of inserts and release memory:
- session.flush();
- session.clear();
- }
-}
-
-tx.commit();
-session.close();]]></programlisting>
-
- </sect1>
-
- <sect1 id="batch-update" >
- <title>バッチ更新</title>
-
- <para>
- データを復元したり更新したりするには同じアイディアを適用します。
- それに加えて、データの行を多く返すクエリに対して有効な
- サーバーサイドのカーソルの利点を生かしたければ
- <literal>scroll()</literal> を使う必要があります。
- </para>
-
-<programlisting><![CDATA[Session session = sessionFactory.openSession();
-Transaction tx = session.beginTransaction();
-
-ScrollableResults customers = session.getNamedQuery("GetCustomers")
- .setCacheMode(CacheMode.IGNORE)
- .scroll(ScrollMode.FORWARD_ONLY);
-int count=0;
-while ( customers.next() ) {
- Customer customer = (Customer) customers.get(0);
- customer.updateStuff(...);
- if ( ++count % 20 == 0 ) {
- //flush a batch of updates and release memory:
- session.flush();
- session.clear();
- }
-}
-
-tx.commit();
-session.close();]]></programlisting>
-
- </sect1>
-
- <sect1 id="batch-statelesssession">
- <title>
- StatelessSessionインターフェイス
- </title>
-
- <para>
- また別の方法として、Hibernateはコマンド指向のAPIを用意しています。
- これは分離オブジェクトの形で、
- データベースとのデータストリームのやり取りに使うことができます。
- <literal>StatelessSession</literal> は関連する永続コンテキストを持たず、
- 高レベルのライフサイクルセマンティクスの多くを提供しません。
- 特にステートレスセッションは、一時キャッシュを実装せず、
- またどのような二次キャッシュやクエリキャッシュとも相互作用しません。
- トランザクショナルなwrite-behindや自動ダーティチェックも実装しません。
- ステートレスセッションを使って行われる操作が、
- 関連するインスタンスへカスケードされることは決してありません。
- コレクションは、ステートレスセッションからは無視されます。
- ステートレスセッションを通して行われる操作は、
- Hibernateのイベントモデルやインターセプタの影響を受けません。
- 一時キャッシュを持たないため、
- ステートレスセッションは別名を持つデータに上手く対処できません。
- ステートレスセッションは低レベルの抽象化であり、JDBCに非常によく似ています。
-
- </para>
-
-<programlisting><![CDATA[StatelessSession session = sessionFactory.openStatelessSession();
-Transaction tx = session.beginTransaction();
-
-ScrollableResults customers = session.getNamedQuery("GetCustomers")
- .scroll(ScrollMode.FORWARD_ONLY);
-while ( customers.next() ) {
- Customer customer = (Customer) customers.get(0);
- customer.updateStuff(...);
- session.update(customer);
-}
-
-tx.commit();
-session.close();]]></programlisting>
-
- <para>
- このコード例では、クエリが返す <literal>Customer</literal>
- インスタンスは即座に（セッションから）分離されることに注意してください。
- これは、どのような永続コンテキストとも決して関連しません。
-
- </para>
-
- <para>
- <literal>StatelessSession</literal> インターフェイスで定義されている
- <literal>insert(), update(), delete()</literal> は、
- 低レベルの直接的なデータベース操作と考えられます。
- 結果として、SQLの <literal>INSERT, UPDATE, DELETE</literal> がそれぞれ即座に実行されます。
- このように、これらは <literal>Session</literal> インターフェイスで定義されている
- <literal>save(), saveOrUpdate(), delete()</literal>
- とは非常に異なる意味を持ちます。
-
- </para>
-
- </sect1>
-
- <sect1 id="batch-direct" revision="3">
- <title>
- DMLスタイルの操作
- </title>
-
- <para>
- すでに議論したように、自動的かつ透過的なオブジェクト/リレーショナルマッピングは、
- オブジェクトの状態の管理であると考えられます。
- これはメモリ内のオブジェクトの状態を利用できるということです。
- そのため（SQLの <literal>データ操作言語</literal> (DML) 文：
- <literal>INSERT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>
- を使って）データベース内のデータを直接操作しても、
- メモリ内の状態には影響を与えません。
- しかしHibernateは、バルクSQLスタイルのDML文実行に対応するメソッドを用意しています。
- これはHibernateクエリ言語（<xref linkend="queryhql">HQL</xref>）
- を通して実行されます。
-
- </para>
-
- <para>
- <literal>UPDATE</literal> と <literal>DELETE</literal> 文の疑似構文は：
- <literal>( UPDATE | DELETE ) FROM? エンティティ名 (WHERE 条件節)?</literal> です。
- 注意すべき点がいくつかあります：
-
- </para>
-
- <itemizedlist spacing="compact">
- <listitem>
- <para>
- from節において、FROMキーワードはオプションです。
- </para>
- </listitem>
- <listitem>
- <para>
- from節では単一のエンティティ名だけが可能で、
- 任意で別名を付けることができます。
- エンティティ名に別名が与えられると、どのようなプロパティ参照も、
- その別名を使って修飾しなければなりません。
- もしエンティティ名に別名が与えられなければ、
- どのようなプロパティ参照も修飾してはなりません。
-
- </para>
- </listitem>
- <listitem>
- <para>
- （暗黙的であれ明示的であれ）<xref linkend="queryhql-joins-forms">結合</xref>
- をバルクHQLクエリ内で指定することはできません。
- サブクエリはwhere節で使うことができます
- サブクエリそのものは、結合を含められます。
-
- </para>
- </listitem>
- <listitem>
- <para>
- where節はオプションです。
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- 例として、HQLの <literal>UPDATE</literal> を実行するには、
- <literal>Query.executeUpdate()</literal> メソッドを使ってください。
- （このメソッドはおなじみのJDBC <literal>PreparedStatement.executeUpdate()</literal>
- から名付けられました）：
- d
- </para>
-
-<programlisting><![CDATA[Session session = sessionFactory.openSession();
-Transaction tx = session.beginTransaction();
-
-String hqlUpdate = "update Customer c set c.name = :newName where c.name = :oldName";
-// or String hqlUpdate = "update Customer set name = :newName where name = :oldName";
-int updatedEntities = s.createQuery( hqlUpdate )
- .setString( "newName", newName )
- .setString( "oldName", oldName )
- .executeUpdate();
-tx.commit();
-session.close();]]></programlisting>
-
- <para>
- HQLの <literal>UPDATE</literal> 文は、デフォルトでは、作用するエンティティの
- <xref linkend="mapping-declaration-version">version</xref> や
- <xref linkend="mapping-declaration-timestamp">timestamp</xref>
- プロパティの値には影響しません。
- これはEJB3の仕様にも受け継がれています。
- しかし <literal>versioned update</literal> を使って、
- <literal>version</literal> や <literal>timestamp</literal>
- プロパティの値を強制的にリセットさせることができます。
- これは <literal>UPD