Reducing Contention for Dynamic Read-Only Cache Groups with Incremental Autorefresh

Most autorefresh and dynamic load operations coordinate their access to the Oracle database for correctness. The default TimesTen coordination behavior could result in contention between autorefresh and dynamic load operations (in extreme cases).

If you have dynamic read-only cache groups with incremental autorefresh, then:

• Multiple dynamic load operations could be blocked by autorefresh operations.

• Autorefresh operations are frequently delayed while waiting for dynamic load operations to complete.

Enabling the DynamicLoadReduceContention database system parameter is useful for dynamic cache groups by changing the way that autorefresh and dynamic load operations coordinate, which results in reduced contention between autorefresh and dynamic load operations.

• Dynamic load operations are never blocked by autorefresh operations (due to additional synchronization).

• Autorefresh operations are not completely delayed by dynamic load operations. Instead, autorefresh operations will wait a short while for concurrently executing dynamic load operations to be notified that a new autorefresh operation is starting. This enables dynamic load operations to synchronize in tandem with concurrently executing autorefresh operations.

Note:

You cannot change the value of the DynamicLoadReduceContention database system parameter if there are any dynamic read-only cache groups or if the cache or replication agents are running. In order to change the value of this parameter, you must unload and drop (and later recreate) any existing dynamic read only cache groups, then stop the cache and replication agents.

The following example sets DynamicLoadReduceContention=1:

call ttDbConfig('DynamicLoadReduceContention','1');

You can query the current value of the DynamicLoadReduceContention parameter.

call ttDbConfig('DynamicLoadReduceContention');

Note:

See ttDBConfig in the Oracle TimesTen In-Memory Database Reference.