| Oracle TopLink開発者ガイド 10g（10.1.3.1.0） B31861-01 |
|
 戻る |
 次へ |
この章では、TopLinkでのトランザクションの実装方法について説明します。この章の内容は次のとおりです。
データベース・トランザクションとは、単一の操作として成功または失敗する操作（作成、読取り、更新または削除）の集合です。失敗したトランザクションは破棄（ロールバック）されるため、データベースは元の状態のまま残ります。トランザクションには、内部トランザクション（TopLinkが提供元）または外部トランザクション（アプリケーション・サーバーなど、アプリケーション外部が提供元）があります。
TopLinkでは、トランザクションは作業ユニット・オブジェクトに含まれます。作業ユニットをセッションから取得し（「作業ユニットの取得」を参照）、そのAPIを使用すると、直接、またはJava Transaction API（JTA）などのJava 2 Enterprise Edition（J2EE）アプリケーション・サーバー・トランザクション・コントローラを使用して、トランザクションを制御できます。
トランザクションは、独自のコンテキスト（論理領域）の中で、他のトランザクションやデータベース操作から独立して実行されます。
トランザクション・コンテキストには境界が設定されています。つまり、トランザクション・コンテキストは次のものを含む定義済の構造を持ちます。
トランザクション内の操作が開始される開始ポイント。トランザクションは、このポイントで操作の実行を開始します。
操作が完了し、トランザクションが変更内容をデータベースに正式に反映しようとする、コミット・ポイント。
同じデータに対する同時（パラレル）トランザクションがどの程度作用し合うかは、構成されているトランザクション分離レベルによって決まります。ANSI/SQLでは、表97-1に示すように、4種類のデータベース・トランザクション分離レベルが定義されています。どのレベルでも、パフォーマンスと次のような望ましくない動作による悪影響の間でトレードオフが発生します。
内容を保証しない読取り: トランザクションが同時トランザクションによって書き込まれた未コミット・データを読み取ります。
非リピータブル・リード: トランザクションがデータを再度読み取り、最初の読取り操作後にコミットされた他のトランザクションによってデータが変更されていることを検出します。
仮読取り: トランザクションが問合せを再度実行します。返されたデータは、最初の読取り操作後にコミットされた他のトランザクションによって変更されています。
| トランザクション分離レベル | 内容を保証しない読取り | 非リピータブル・リード | 仮読取り |
|---|---|---|---|
|
非コミット読取り |
○ |
○ |
○ |
|
コミット読取り |
× |
○ |
○ |
|
リピータブル・リード |
× |
× |
○ |
|
シリアライズ可能 |
× |
× |
× |
トランザクションがコミットされるたびに、データベースではデータに加えられたすべての変更のログが記録されます。トランザクション内の操作がすべて成功した場合は、データベースが変更されますが、トランザクションの一部が失敗した場合は、ログを使用して変更内容がロールバックされます。
通常のトランザクションと同様に、作業ユニット・トランザクションは次のものを提供します。
作業ユニットの操作は、作業ユニットのコンテキスト内で行われ、書込みはコミット時までデータベースから分離されます。作業ユニットは、独自の内部キャッシュ内のオブジェクトのコピー（クローン）に対して変更を実行し、成功した場合はデータベースおよびセッション・キャッシュ内のオブジェクトに変更内容を適用します。
スタンドアロンのTopLinkアプリケーションの場合、作業ユニットを使用してトランザクション境界が設定されます。
アプリケーションにコンテナ管理トランザクションを提供するJ2EEコンテナが含まれている場合、アプリケーション・サーバーでは、独自のトランザクション・サービスを使用して、トランザクションの境界が設定されます。TopLinkの外部トランザクション・コントローラを指定することで、コンテナのトランザクション・サービスと統合するように、TopLinkを構成します。
TopLinkの外部トランザクション・コントローラのクラスでは、作業ユニットがアプリケーション・サーバーのトランザクション・サービスと統合されます。外部トランザクション・コントローラを使用することで、アプリケーションは、複数のデータ・ソースにわたりアプリケーション・サーバーに管理されているトランザクションを使用できます。外部トランザクション・コントローラでは、アプリケーション・サーバーのトランザクション・サービスと作業ユニットの間でやりとりされるメッセージとコールバックが調整されます。
外部トランザクション・コントローラを使用できるようにアプリケーションを構成した場合（「サーバー・プラットフォームの構成」を参照）、作業ユニットは、外部トランザクションの一部として実行されます。作業ユニットは依然として独自の内部操作を管理しますが、変更内容をデータベースとセッション・キャッシュに書き戻すよう外部トランザクションに指示されるのを待ちます。
トランザクションは作業ユニット・コンテキストの外部で発生し、アプリケーション・サーバーのトランザクション・サービスによって制御されるため、例外はアプリケーション・サーバーによって開始されたコールバック中など、アプリケーション・コードの外部で発生するので、エラーの診断および修正が困難になる場合があります。
作業ユニットは、次のものと統合できます。
Java Transaction API（JTA）は、トランザクション・マネージャと対話する際に使用するAPIです。
JTAを使用すると、アプリケーションは分散トランザクションを使用できます。JTAを実装するトランザクション・マネージャでは、トランザクション管理および接続プールが提供され、アプリケーションはJTAを使用して複数のデータ・ソースと透過的に対話できます。
詳細は、「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
CORBA Object Transaction Service（OTS）の仕様は、Common Object Request Brokers Architecture（CORBA）オブジェクト・サービス・モデルの構成要素で、Object Request Broker（ORB）実装の標準です。サーバーの中には、JTAのJava API（「JTAによって制御されるトランザクション」を参照）ではなくOTSのJava APIを実装しているものがあります。
作業ユニットとともにTopLink OTSのサポートを使用すると、JTAをサポートしないサーバーのJava OTSインタフェースに直接アクセスできます。
アプリケーションとOTSトランザクション・サービスを統合するには、カスタム・サーバー・プラットフォームを使用するようにアプリケーションを構成する必要があります（「サーバー・プラットフォームの構成」を参照）。
詳細は、「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
コンテナ管理の永続性を使用するエンティティBeanは、クライアントまたはコンテナによって境界が設定されたトランザクションに参加することができます。
クライアントによって境界が設定されたトランザクションとは、エンティティBeanのクライアントが直接、javax.transaction.UserTransactionインタフェースを使用して境界を設定したトランザクションです。
コンテナによって境界が設定されたトランザクションとは、EJBデプロイメント・ディスクリプタに指定されたトランザクション属性に基づいて、トランザクション内のEJBの起動が自動的にラップされるトランザクションです。
EJBを伴うトランザクションでは、トランザクションが2フェーズ・コミット・プロセスを開始するまで待ってから、データベースが更新されます。これにより、次のことが可能になります。
変更されたデータのみがデータ・ソースに書き込まれるようにするSQL最適化
データベース制約を考慮した適切な更新順序
詳細は、「作業ユニットとCMPの統合」を参照してください。
作業ユニットは、データベース・トランザクションの分離とは直接の関係はありません。作業ユニットでは問合せがデータベース・トランザクション外部（および、キャッシュとの対話によってデータベース自体の外部）で実行される場合があるため、データベースはこれら外部のデータとその可視性を制御できません。
ただし、デフォルトでは、TopLinkは、基礎となるデータベースに構成されたデータベース・トランザクション分離タイプとは無関係のトランザクション分離レベルを提供します。
各作業ユニット・インスタンスは、登録済オブジェクトの独自コピー（クローン）に対して操作を行います（「クローンと作業ユニット」を参照）。この場合、作業ユニットでは、オブジェクトの変更に対する問合せを1つの作業ユニット内で実行できるAPIにより（「一致する問合せおよびディスクリプタの使用」を参照）、読取りコミット操作を行います。
オプティミスティック・ロック、オプティミスティック読取りロックまたはペシミスティック・ロックを使用すると、並行性の管理性が向上します（「ロックと作業ユニット」を参照）。
変更内容がデータベースにコミットされるのは、作業ユニットのcommitメソッドが（直接、または外部トランザクション・コントローラを介して）コールされた場合のみです。
各トランザクション分離レベルでTopLinkを構成および使用する方法とトランザクション分離レベルの制限の詳細は、「データベース・トランザクション分離レベル」を参照してください。
この項では、次の内容を含む、TopLinkに固有のトランザクションの概念について説明します。
TopLinkの作業ユニットはトランザクションを単純化し、トランザクションのパフォーマンスを向上させます。次の利点があるため、TopLinkでデータベースへの書込みを行う際には作業ユニットを使用することをお薦めします。
正確な変更のみをフィールド・レベルで更新することにより、コミット時にデータベースに送信するSQLの量が最小限に抑えられます。
トランザクション操作を独自のメモリー領域に分離することにより、データベース・トラフィックが減少します。
キャッシュ間でオブジェクトではなくチェンジ・セットを受け渡すことにより、複数のキャッシュを使用するアプリケーションでキャッシュ・コーディネーションが最適化されます。
オブジェクトの変更を独自のトランザクション領域に分離することにより、同じオブジェクトに対するパラレル・トランザクションが可能になります。
SQLの順序を自動的にメンテナンスすることにより、参照整合性が保証され、デッドロックが最小限に抑えられます。
データベースの挿入、更新および削除操作の順序を指定することにより、マップされるオブジェクトの参照整合性が維持されます。
双方向参照が自動的に解決されます。
変更の追跡や記録をアプリケーションで行う必要がなくなります。
到達可能性による永続性を使用することで、永続性が単純化されます（「既存のターゲット・オブジェクトへの新規ソースの関連付け」を参照）。
クライアント・アプリケーションがセッション・オブジェクトから作業ユニットを取得します。
クライアント・アプリケーションがTopLinkに対して問合せを行い、変更対象のキャッシュ・オブジェクトを取得した後、そのキャッシュ・オブジェクトを作業ユニットに登録します。
作業ユニットでは、オブジェクトの変更ポリシーに従って、オブジェクトを登録します。変更ポリシーが登録に与える影響の詳細は、「作業ユニットおよび変更ポリシー」を参照してください。
デフォルトでは、各オブジェクトが登録されるたびに、作業ユニットはセッション・キャッシュまたはデータベースのオブジェクトにアクセスし、バックアップ・クローンと作業クローンを作成します（「クローンと作業ユニット」を参照）。作業ユニットが作業クローンをクライアント・アプリケーションに返します。
作業ユニットが返した作業オブジェクトを、クライアント・アプリケーションで変更します。
クライアント・アプリケーション（または外部トランザクション・コントローラ）がトランザクションをコミットします。
作業ユニットでは、オブジェクトの変更ポリシーに従って、各登録オブジェクトのチェンジ・セットを計算します。変更ポリシーがチェンジ・セットの計算に与える影響の詳細は、「作業ユニットおよび変更ポリシー」を参照してください。
デフォルトでは、コミット時には、作業ユニットは作業クローンとバックアップ・クローンを比較して、チェンジ・セットを計算します（つまり、必要な最小限の変更を決定します）。バックアップ・クローンとの比較により、同じオブジェクトが同時に変更されても検出される変更が不適切になることがなくなります。次に、作業ユニットは、新しいオブジェクトや変更されたオブジェクトをデータベースに対してコミットしようとします。
トランザクションのコミットが成功した場合、作業ユニットは変更内容を共有セッション・キャッシュにマージします。失敗した場合は、共有キャッシュ内のオブジェクトは不変です。詳細は、「トランザクションのコミットとロールバック」を参照してください。
変更がない場合は、作業ユニットは新しいトランザクションを開始しません。
例97-1は、デフォルトのライフ・サイクルをコードで示したものです。
// The application reads a set of objects from the database Vector employees = session.readAllObjects(Employee.class); // The application specifies an employee to edit . . . Employee employee = (Employee) employees.elementAt(index); try { // Acquire a unit of work from the session UnitOfWork uow = session.acquireUnitOfWork(); // Register the object that is to be changed. Unit of work returns a clone // of the object and makes a backup copy of the original employee Employee employeeClone = (Employee)uow.registerObject(employee); // Make changes to the employee clone by adding a new phoneNumber. // If a new object is referred to by a clone, it does not have to be // registered. Unit of work determines it is a new object at commit time PhoneNumber newPhoneNumber = new PhoneNumber("cell","212","765-9002"); employeeClone.addPhoneNumber(newPhoneNumber); // Commit the transaction: unit of work compares the employeeClone with // the backup copy of the employee, begins a transaction, and updates the // database with the changes. If successful, the transaction is committed // and the changes in employeeClone are merged into employee. If there is an // error updating the database, the transaction is rolled back and the // changes are not merged into the original employee object uow.commit(); } catch (DatabaseException ex) { // If the commit fails, the database is not changed. The unit of work should // be thrown away and application-specific action taken } // After the commit, the unit of work is no longer valid. Do not use further
作業ユニットでは、オブジェクトのディスクリプタ用に構成する変更ポリシーに基づいて、登録オブジェクトの変更を追跡します。変更がない場合は、作業ユニットは新しいトランザクションを開始しません。
表97-2は、TopLinkに用意されている変更ポリシーをまとめたものです。
表97-2 TopLinkの変更ポリシー
| 変更ポリシー | 適用対象 |
|---|---|
|
|
広範囲のオブジェクト変更特性。 デフォルトの変更ポリシー。 |
|
|
わずかな属性のみを持つオブジェクトや、多数の属性を持ち、しかも変更される属性が多いオブジェクト。 |
|
|
多数の属性を持つが変更される属性が少ないオブジェクト。 これは、パフォーマンスが最も高い変更ポリシーです。 これは、OC4JのEJB 3.0永続性または2.n CMPにおけるデフォルトの変更ポリシーです。 |
詳細は、「変更ポリシーの構成」を参照してください。
DeferredChangeDetectionPolicyは、すべての永続オブジェクトがデフォルトで使用する変更ポリシーです。
このオプションを使用すると、広範なオブジェクト変更特性に関して、作業ユニットのコミットで良好なパフォーマンスが得られます。
DeferredChangeDetectionPolicyで構成されたディスクリプタを持つオブジェクトを作業ユニットに登録すると（「遅延変更検出ポリシーの構成」を参照）、オブジェクトのバックアップ・クローンが作成され（「クローンと作業ユニット」を参照）、作業ユニットは、コミット時に、バックアップ・クローンと元のオブジェクトを属性ごとに比較して、変更を計算します。
この変更ポリシーは、すべてのマッピング・タイプに適用できます。
ObjectChangeTrackingPolicyを使用すると、1つの属性が変更された場合にかぎり、オブジェクトをチェンジ・セットの計算に含めることによって、作業ユニットのトランザクションのコミットが最適化されます。
このオプションを使用すると、わずかな属性のみを持つオブジェクトや、多数の属性を持ち、しかも変更される属性が多いオブジェクトに関して、作業ユニットのコミットのパフォーマンスが向上します。
ObjectChangeTracking変更ポリシーで構成されたディスクリプタを持つオブジェクトを作業ユニットに登録すると、オブジェクトのバックアップ・クローンが作成されます。作業ユニットは、コミット時に、1つ以上の属性が変更された場合にかぎり（オブジェクトのhasChangesメソッドがtrueを返した場合）、バックアップと現在のオブジェクトを比較して変更を計算します。登録されたオブジェクトに変更がない場合は、作業ユニットはそのオブジェクトとバックアップ・クローンを比較しません。
この変更ポリシーは、マッピング・タイプのサブセットに適用できます（「マッピングでの変更ポリシーのサポート」を参照）。
TopLinkでは、使用しているEJBバージョンとアプリケーション・サーバーに応じて、様々なレベルのオブジェクト・レベル変更追跡ポリシーをサポートしています。
TopLinkでCMP統合を提供するアプリケーション・サーバーにデプロイされたCMPアプリケーションの場合（「アプリケーション・サーバーのサポート」を参照）、ObjectChangeTrackingPolicyを使用してコンテナ管理の永続性を備えたエンティティBeanのディスクリプタを構成すると、TopLinkコードには、TopLink ChangeTrackerインタフェースを実装するための具象サブクラスがデプロイ時に生成されます（「オブジェクト変更追跡ポリシーの構成」を参照）。
|
注意: 前述の内容は、EJB 3.0永続性を使用するアプリケーションにも適用されます。 |
AttributeChangeTrackingPolicyは、属性レベルですべてのオブジェクトの変更を追跡して、作業ユニットのトランザクションのコミットを最適化します。これにより、バックアップ・クローンの作成、および比較による変更検出という、作業ユニットの2つの操作が不要になります。
このオプションを使用すると、多数の属性を持つが変更される属性が少ないオブジェクトに関する作業ユニットの、コミットのパフォーマンスが向上します。通常は、この変更ポリシーを使用すると、最も高いパフォーマンスが得られます。
この変更ポリシーは、マッピング・タイプのサブセットに適用できます（「マッピングでの変更ポリシーのサポート」を参照）。
|
注意: FieldsLockingPolicyのインスタンスを使用している場合（「オプティミスティック・フィールド・ロック・ポリシー」を参照）、AttributeChangeTrackingPolicyは使用できません。 |
TopLinkでは、使用しているEJBバージョンとアプリケーション・サーバーに応じて、様々なレベルのオブジェクト・レベル変更追跡ポリシーをサポートしています。
プレーンJavaオブジェクトまたはOC4J以外のアプリケーション・サーバーの場合、クラスにAttributeChangeTrackingPolicyを適用するには、クラスのディスクリプタをAttributeChangeTrackingPolicyで構成し、そのクラスにChangeTrackerインタフェースを実装する必要があります（「属性変更追跡ポリシーの構成」を参照）。
OC4JのCMPを使用する場合に、このパフォーマンス拡張機能を利用するには、ディスクリプタをデフォルトのDeferredChangeDetectionPolicyで構成すると、TopLinkで自動的にAttributeChangeTrackingPolicyが適用されます。プロジェクトのディスクリプタを別の変更ポリシーで構成すると、TopLinkではその構成を優先し、AttributeChangeTrackingPolicyを適用しません。
TopLink対応のCMPアプリケーションをOC4Jにデプロイする際に、TopLinkでは、デフォルトのDeferredChangeDetectionPolicyで構成されたマップ済のクラスごとにコード生成を使用して、この構成をAttributeChangeTrackingPolicyで自動的にオーバーライドし、必要なインタフェースをクラスに実装します。
TopLinkでは、次のいずれかのマッピング・タイプを使用している属性については、その他の変更追跡ポリシー（DeferredChangeDetectionPolicy以外のポリシー）がサポートされています。
トランスフォーメーション・マッピング（不変マッピングのみ）
EISトランスフォーメーション・マッピング（不変マッピングのみ）
TopLinkでは、その他のマッピング・タイプを使用する属性に対しては、DeferredChangeDetectionPolicy（「遅延変更検出ポリシー」を参照）を使用します。
DeferredChangeDetectionPolicyまたはObjectLevelChangeTrackingPolicy（「遅延変更検出ポリシー」を参照）を使用する場合、作業ユニットは登録された元のオブジェクトのコピーを2つ保持します。
作業クローン
バックアップ・クローン
作業クローンの変更後にトランザクションがコミットされると、作業ユニットは作業クローンをバックアップ・クローンと比較し、変更内容をデータベースに書き込みます。作業ユニットは、クローンを使用してパラレル作業ユニット（「ネストした作業ユニットとパラレル作業ユニット」を参照）の存在を可能にしています。これは、マルチユーザーの3層アプリケーションにおいては必須です。
TopLinkのクローニング・プロセスは、登録されているオブジェクトのマップ済属性のみをクローン化し、インダイレクションをトリガーしないかぎりインダイレクション・オブジェクトで停止するため、効率的です。詳細は、「インダイレクションの構成」を参照してください。
ディスクリプタ・コピー・ポリシーを使用して、クローニング・プロセスをカスタマイズできます。詳細は、「コピー・ポリシーの構成」を参照してください。
クローンの作成元である作業ユニットをコミットした後は、トランザクションが失敗してロールバックされた場合でも、そのクローンを使用しないでください。クローンはトランザクションで使用される作業コピーであるため、トランザクションがコミットされると同時に（成功したかどうかには関係なく）、使用をやめる必要があります。作業ユニットのトランザクションのコミット後に、インスタンス化されていないクローンのValueHolderにアクセスすると、例外が発生します。トランザクションのコミットの成功後にクローンを使用できるのは、「コミット後の作業ユニットの再開」で説明する拡張APIを使用する場合のみです。
ネストした作業ユニットおよびパラレル作業ユニットの使用の詳細と例は、「ネストした作業ユニットまたはパラレル作業ユニットの使用」を参照してください。
作業ユニット（子）を別の作業ユニット（親）内にネストさせることができます。ネストした作業ユニットは、変更内容をデータベースにコミットしません。かわりに、親作業ユニットに変更内容を渡し、親がコミット時に変更内容をコミットしようとします。ネストした作業ユニットを使用すると、大規模なトランザクションを小さな独立したトランザクションに分割でき、次のことが保証されます。
ネストした各作業ユニットでの変更内容は、グループとしてコミットされるか、失敗します。
ネストした作業ユニットが失敗しても、親作業ユニットにおける他の操作に対するトランザクションのコミットまたはロールバックには影響を与えません。
変更内容が1つのトランザクションとしてデータベースに示されます。
作業ユニットではオブジェクトのコピーが操作されるため、同じオブジェクトを複数の作業ユニット・インスタンスで並行して変更できます。TopLinkでは、並行性の問題は作業ユニットで変更をコミットする際にすべて解決されます。
作業ユニット・トランザクションがコミットされると、そのトランザクションは成功するか、失敗してロールバックされるかのいずれかです。トランザクションのコミットは、アプリケーションまたはJ2EEコンテナによって開始できます。
コミット時には、作業ユニットは作業クローンとバックアップ・クローンを比較して、チェンジ・セットを計算します（つまり、必要な最小限の変更を決定します）。変更には、既存のオブジェクトの更新または削除、および新規オブジェクトの作成があります。その後、作業ユニットはデータベース・トランザクションを開始し、データベースに変更内容を書き込もうとします。変更がすべて正常にデータベースでコミットされると、作業ユニットは変更されたオブジェクトをセッション・キャッシュにマージします。いずれかの変更がデータベースで失敗すると、作業ユニットはデータベース上の変更内容をすべてロールバックします。変更内容はセッション・キャッシュにマージしません。
作業ユニットは、1対1マッピングと1対多マッピングの外部キー情報を使用して、コミット順序を計算します。トランザクションのコミット中に制約に関する問題が発生した場合は、マッピングの定義を確認してください。registerObjectメソッドを使用してオブジェクトを登録する順序は、コミット順序には影響を与えません。
アプリケーションでJTAを使用している場合、作業ユニットのトランザクションのコミット動作は、JTAを使用しないアプリケーションの場合とは異なります。ほとんどの場合、作業ユニットは外部トランザクションにアタッチされます。トランザクションが存在しない場合は、作業ユニットがトランザクションを作成します。この違いは、コミット動作に次のような影響を与えます。
作業ユニットが既存のトランザクションにアタッチされた場合、作業ユニットはcommitコールを無視します。外部トランザクション全体が完了すると、作業ユニットがコミットされます。
作業ユニットが外部トランザクションを開始した場合、そのトランザクションは、作業ユニットのcommitコールを外部トランザクションのコミット・リクエストとして扱います。その後、外部トランザクションはそれ自体のコミット・コードをデータベース上でコールします。
どちらの場合も、データベース接続を所有しているのは外部トランザクションであるため、外部トランザクションのみがデータベース上でcommitをコールできます。
詳細は、「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
作業ユニットのトランザクションのコミットは、ユニット全体として成功するかユニット全体として失敗するかのいずれかの結果しかありません。データベースへの変更内容の書込みが失敗すると、作業ユニットはデータベースを以前の状態にロールバックします。データベースは何も変更されず、作業ユニットは変更内容をセッション・キャッシュにマージしません。
JTA環境では、作業ユニットはデータベース接続を所有しません。この場合、作業ユニットはロールバック・コールをデータベースではなく外部トランザクションに送信します。外部トランザクションは、ロールバック・コールをトランザクションのロールバック・リクエストとして扱います。
詳細は、「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
作業ユニットでは、オブジェクトの主キー属性は変更できません。これはサポートされていない操作であり、この操作を行うと予期しない動作（例外またはデータベースの破損）を引き起こします。
一意制約を持つオブジェクトのインスタンスを別のインスタンスと置き換える場合は、「作業ユニットのsetShouldPerformDeletesFirstメソッドの使用」を参照してください。
デフォルトでは、作業ユニットは、広範囲なオブジェクト変更特性に対して、チェンジ・セットを効率的に計算します。この他にも、ユーザーが作業ユニットを使用してアプリケーションのパフォーマンスを拡張できる様々な方法が用意されています。
パフォーマンスを向上させる1つの方法として、代替の変更ポリシーの使用があげられます（「作業ユニットおよび変更ポリシー」を参照）。
パフォーマンスのオプションの詳細は、「作業ユニットの最適化」を参照してください。
oracle.toplink.sessions.UnitOfWorkのインスタンスはインスタンス化しません。かわりに、この作業ユニットは、oracle.toplink.sessions.Sessionのインスタンスまたは別の作業ユニットから取得します。
セッション作成の詳細は、「セッションの作成」を参照してください。
作業ユニットの取得の詳細は、「作業ユニットの取得」を参照してください。
作業ユニットの基本APIの使用方法の詳細は、「作業ユニットの基本APIの使用」を参照してください。
作業ユニットの拡張APIの使用方法の詳細は、「作業ユニットの拡張APIの使用」を参照してください。
作業ユニットは、インタフェースoracle.toplink.sessions.Sessionを拡張し、通常のセッションAPIをすべて実装したものです。作業ユニットのセッションAPIを使用する際には、次をお読みください。
作業ユニットは、通常のセッションの場合と同様の一連のデータベース・アクセス・メソッドを提供します。
これらのメソッドは、作業ユニットからコールされると、作業ユニット内のオブジェクトにアクセスし、選択されたオブジェクトを自動的に登録して、クローンを返します。
そのため、registerObjectおよびregisterAllObjectsメソッドをコールする必要がなくなりますが、「オブジェクトの作成」と「既存のターゲット・オブジェクトへの新規ソースの関連付け」で説明するオブジェクトの登録についての制限に注意してください。
すべてのセッションに使用できる一般的なロックAPIの詳細は、次を参照してください。
作業ユニット用のロックAPIの詳細は、「forceUpdateToVersionFieldを使用したオプティミスティック読取りロックの使用」を参照してください。
