About Oracle ADF Business Components Cache Management

Oracle ADF Business Components uses a sophisticated caching system to improve performance and maintain consistent views of data. Understanding how the caching system works is important for understanding how your business components will behave at runtime.

Every view object instance controls its own cache, called its view cache. This cache holds a collection of view rows. When a view object retrieves data from the datasource, it creates a view row to represent that row of data and adds the instance to the view cache. Each view attribute of this view row is populated, but how it's populated depends on whether or not the view attribute is mapped to an entity attribute.

Populating View Attributes Not Mapped to Entity Attributes

If a view attribute is not mapped to an entity attribute, the view attribute is populated directly with the value from the datasource.

For example, consider a view object, CustomerOrdersView, with the SQL query

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

and with view attributes:

CustomerId
CustFirstName
CustLastName
OrderId
OrderDate
OrderTotal

Suppose that OrderId, OrderDate, and OrderTotal are not mapped to any entity attributes.

Now, suppose an instance of CustomersOrdersView, MyCustomersAndOrders, executes its query. The first row returned by the query is

CUSTOMER_ID	CUST_FIRST_NAME	CUST_LAST_NAME	ORDER_ID	ORDER_DATE	ORDER_TOTAL
501	John	Doe	1137	01-AUG-03	573

Then the OrderId, OrderDate, and OrderTotal view attributes for the first view row added to the view cache will be directly populated with these values.

MyCustomersAndOrdersCache, a single view row.

Populating View Attributes Mapped to Entity Attributes

If a view attribute is mapped to an entity attribute, the view object instance follows this procedure:

The view object finds the entity object usage containing the entity attribute.
The view object checks by primary key, to see if the appropriate entity object instance has already been created. If not, it creates the entity object instance and populates the mapped entity object attribute with the value from the datasource. The entity object instance is added to another cache, the entity cache.
The view object attribute is populated with a pointer to the entity object attribute.

For example, consider the CustomerOrdersView view object definition mentioned above. Suppose the view object attributes CustomerId , CustFirstName, and CustLastName are mapped to entity object attributes with the same name in an entity object called Customers. When the first view row of the MyCustomersAndOrders view object instance is created, it will be populated with pointers to a row in Customers' entity cache:

Two caches are populated with pointers.

The Impact of the Entity Cache

Using the entity cache allows you to do the following:

Post changes to the database. Since entity objects control all DML operations, you can not post changes to data stored directly in the view cache.
Save space between view object instances. Multiple view object instances can contain rows that map to the same entity object instance. For example, two independent instances of CustomersOrdersView will each contain a view row referring to Customer 501, as will an independent instance of a view object with the SQL
SELECT * FROM CUSTOMERS

By basing the view attributes CustomerId, CustFirstName, and CustLastName from both view object definitions on the same entity object attributes, the data 501, "John", and "Doe" will only need to be stored once (in Customers' entity cache) rather than three times (in view caches for both instances of CustomersOrdersView and for the instance of CustomersView).
Save space within a view instance's cache. MyCustomersAndOrders ' cache will return many rows corresponding to Customer 501: One for each order that Customer 501 has placed. By basing the view attributes CustomerId, CustFirstName, and CustLastName on corresponding entity cache, the data 501, "John", and "Doe" will only need to be stored once (in a single row of Customers ' entity cache) rather than once for each of Customer 501's rows.
Keep a consistent view of data. If you change the value of data stored directly in a view row, that change will only be visible within that view row. Other view object instances containing the same data will become inconsistent. For example, if you change the view attribute OrderDate in one row of MyCustomersAndOrders, and that attribute is not mapped to an entity attribute, the value will become inconsistent with other views of the same order. However, if you change the view attribute CustFirstName in one row of MyCustomersAndOrders, and that attribute is mapped to an entity object attribute, the change will actually happen in the entity object cache, and be visible with all other views of the same customer.
Use business logic. By placing business logic in entity objects, and basing view attributes on entity attributes, you can use and reuse the same business logic in many different views of the data.

If you do not need any of these advantages, however, you may want to eliminate the entity cache, because creating and storing the pointers adds a small amount of overhead. For more information, see the related topics list.

Caches and Application Modules

Each application module instance has an entirely separate set of caches. For this reason, it is very important that you know how to tune Oracle ADF Business Components so that it will scale for large numbers of application module instances, if you expect to have a large number of simultaneous users. For more information, see the related topics list.