Skip Headers

Oracle TopLink Developer's Guide 10g Release 3 (10.1.3) B13593-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# Cache Optimization

Cache coordination (see "Understanding Cache Coordination") is one way to allow multiple, possibly distributed, instances of a session to broadcast object changes among each other so that each session's cache can be kept up-to-date.

However, cache coordination is best suited to applications with specific characteristics ("When to use Cache Coordination"). Before implementing cache coordination, tune the TopLink cache for each class using alternatives such as object identity type (see "Configuring Cache Type and Size at the Descriptor Level"), cache invalidation (see "Cache Invalidation"), or cache isolation (see "Cache Isolation"). Doing so lets you configure the optimal cache configuration for each type of class (see Table 11-11) and may eliminate the need for distributed cache coordination altogether.

Table 11-11 Identity Map and Cache Configuration by Class Type

Class Type | Identity Map Options | Cache Options
--- | --- | ---
read-only | soft, hard, or fullFoot 1 |
read-mostly | soft or hard | cache invalidation or cache coordination
write-mostly | weak | cache invalidation

Footnote 1 If the number of instances is finite.

If you do use cache coordination, use JMS for cache coordination rather than RMI. JMS is more robust, easier to configure, and runs asynchronously. If you require synchronous cache coordination, use RMI.

You can configure a descriptor to control when the TopLink runtime will refresh the session cache when an instance of this object type is queried (see "Configuring Cache Refreshing"). Oracle does not recommend the use of Always Refresh or Disable Cache Hits.

Using Always Refresh may result in refreshing the cache on queries when not required or desired. As an alternative, consider configuring cache refresh on a query by query basis (see "Refreshing the Cache").

Using Disable Cache Hits instructs TopLink to bypass the cache for object read queries based on primary key. This results in a database round trip every time an object read query based on primary key is executed on this object type, negating the performance advantage of the cache. When used in conjunction with Always Refresh, this option ensures that all queries go to the database. This can have a significant impact on performance. These options should only be used in specialized circumstances.