Oracle ADF Business Componentsは、パフォーマンスを改善し、一貫したデータ・ビューを維持するために高度なキャッシュ・システムを使用します。キャッシュ・システムがどのように機能するかを理解しておくことは、ビジネス・コンポーネントの実行時の動作を理解する上で重要です。
ビュー・オブジェクト・インスタンスは、ビュー・キャッシュと呼ばれるそれぞれのキャッシュを制御します。このキャッシュではビュー行のコレクションが保持されます。ビュー・オブジェクトによってデータソースからデータが取得されると、そのデータ行を表すビュー行が作成され、そのインスタンスがビュー・キャッシュに追加されます。このビュー行の各ビュー属性に値が移入されますが、その方法はビュー属性がエンティティ属性にマップされるかどうかによって異なります。
ビュー属性がエンティティ属性にマップされない場合、ビュー属性にはデータソースからの値が直接移入されます。
たとえば、次のSQL問合せを使用する、CustomerOrdersView
というビュー・オブジェクトについて考えてみます。
SELECT CUSTOMERS.CUSTOMER_ID, CUSTOMERS.CUST_FIRST_NAME,
CUSTOMERS.CUST_LAST_NAME, Orders.ORDER_ID, Orders.ORDER_DATE,
Orders.ORDER_TOTAL
FROM CUSTOMERS, ORDERS Orders
WHERE CUSTOMERS.CUSTOMER_ID = Orders.CUSTOMER_ID
また次のビュー属性についても考えてみます。
CustomerId
CustFirstName
CustLastName
OrderId
OrderDate
OrderTotal
OrderId
、OrderDate
およびOrderTotal
はエンティティ属性にマップされないものとします。
ここで、CustomersOrdersView
、MyCustomersAndOrders
のインスタンスがその問合せを実行します。この問合せの結果返される最初の行は、次のとおりです。
CUSTOMER_ID | CUST_FIRST_NAME | CUST_LAST_NAME | ORDER_ID | ORDER_DATE | ORDER_TOTAL |
---|---|---|---|---|---|
501 | John | Doe | 1137 | 01-AUG-03 | 573 |
次に、ビュー・キャッシュに追加された最初のビュー行のOrderId
、OrderDate
およびOrderTotal
の各ビュー属性に、これらの値が直接移入されます。
ビュー属性がエンティティ属性にマップされる場合は、ビュー・オブジェクト・インスタンスは次のプロシージャに従います。
たとえば、前述のCustomerOrdersViewのビュー・オブジェクト定義を考えてみます。CustomerId
、CustFirstName
およびCustLastName
の各ビュー・オブジェクト属性は、Customers
と呼ばれるエンティティ・オブジェクトにある同じ名前のエンティティ・オブジェクト属性にマップされます。MyCustomersAndOrdersビュー・オブジェクト・インスタンスの最初のビュー行が作成されると、その行には、Customers
のエンティティ・キャッシュの行へのポインタが移入されます。
エンティティ・キャッシュを使用すると、次の操作を実行できます。
CustomersOrdersView
の2つの独立したインスタンスには、それぞれCustomer 501を参照するビュー行があります。これは、SQLを使用したビュー・オブジェクトの独立したインスタンスの場合と同様です。
SELECT * FROM CUSTOMERS
両方のビュー・オブジェクト定義からのCustomerId
、CustFirstName
およびCustLastName
の各ビュー属性を同じエンティティ・オブジェクト属性に基づいて作成すると、501、JohnおよびDoeの各データの保存は、3回(CustomersOrdersView
の両方のインスタンスおよびCustomersOrdersView
のインスタンスのビュー・キャッシュに保存)ではなく1回(Customers
のエンティティ・キャッシュに保存)のみ必要となります。
MyCustomersAndOrders
のキャッシュからは、Customer 501に対応する多数の行が返されます。Customer 501が実行した各注文に対して1行ずつ返されるためです。CustomerId
、CustFirstName
およびCustLastName
の各ビュー属性を対応するエンティティ・キャッシュに基づいて作成すると、501、JohnおよびDoeの各データの保存は、Customer 501の行ごとに1回ずつではなく、(Customers
のエンティティ・キャッシュの1行に)1回のみ必要となります。
MyCustomersAndOrders
のある行のOrderDate
ビュー属性が変更され、その属性がエンティティ属性にマップされない場合、同じ順序の他のビューについて値の一貫性が失われます。一方、MyCustomersAndOrders
のある行のCustFirstName
ビュー属性が変更され、その属性がエンティティ・オブジェクト属性にマップされる場合、実際の変更はエンティティ・オブジェクト・キャシュで実行され、同じ顧客の他のすべてのビューとともに参照可能になります。
ただし、前述のような活用をしない場合は、エンティティ・キャッシュを削除できます。そうすることで、ポインタの作成および保存によるオーバーヘッドのわずかな増加を避けることができます。詳細は、関連項目のトピックを参照してください。
各アプリケーション・モジュール・インスタンスには、それぞれまったく異なるキャッシュのセットがあります。このため、多数の同時ユーザーのアクセスが予想される場合は、Oracle ADF Business Componentsを多数のアプリケーション・モジュール・インスタンスに対応してスケーリングできるように調整する方法の理解が非常に重要です。詳細は、関連項目のトピックを参照してください。
Oracle ADF Business Componentsの概要
Oracle ADFビュー・オブジェクトについて
ビュー・オブジェクト属性について
Oracle ADFエンティティ・オブジェクトについて
エンティティ・オブジェクト属性について
ビュー・オブジェクト・インスタンスとビュー・リンク・インスタンスについて
アプリケーション・モジュールについて
エンティティ・キャッシュの回避
ビュー・キャッシュの回避
複数のトランザクションのスケーリング
Copyright © 1997, 2007, Oracle. All rights reserved.