Caching is a widely used technique that favors scalability, performance and affordability against possibly maintainability, data consistency, and accuracy.
As we stated above, with caching, you introduce the possibility of data consistency issues. This data inconsistency may occur when an API changes a reference data record in one JVM while another transaction is using another copy of that reference data in another JVM.
In this section, we describe strategies you can use to mitigate the data consistency issues.
Strategy 1 - Trade-off Performance and Affordability against Data Consistency
In this strategy, you may ask yourself the question. First, does the possibility of data consistency exist? Since the refreshes are done asynchronously, the answer is yes. The next question is, what is the probability of a data consistency? One of the factors that this answer depends on is the transaction volume. There may be more. For example, if you were to make the reference data changes at night when transaction volumes are low, you may decide that the probability of data consistency is potentially low. The last question you need to ask is, what is the impact of an inconsistent data? If you determine that the impact is insignificant, then you may decide to go with this strategy. The decision is yours to make.
Strategy 2 - Trade-off Performance and Affordability against Maintainability while keeping Data Consistency
In this strategy, you control updates against the cacheable reference data to eliminate any possibility of data consistency. One approach is to place the cacheable reference tables into a separate tablespace.
In addition, with Oracle, using the following command, you alter the tablespace to only allow reads:
alter tablespace <tablespace name> read only;
Oracle ensures that these tables are not modified without your knowledge. To modify the cached reference data, you then alter the tablespace back to read/write and modify the reference data through the Applications Manager. To be safe, you would probably do this when there is very little transactional activity on the system. When you are done, you can then mark that tablespace as read only with the following command:
alter tablespace <tablespace name> read write;When a record of a cached table is modified by a API, the local cache manager sends change notification messages to all the other cache managers in the system. These messages are sent sequentially - going from one cache manager to the next. The time to notify all cache managers is dependent on the number of cache managers - the more managers, the longer the notification process.
You can use the System Management Console to manually refresh the cache for an application server. Go to the Details page for each application server or the agent instance and press the "Clear Cache" icon. The cache for the application server is cleared.
The list of cache managers are dynamically maintained in the YFS_HEARTBEAT database table. servers, integration servers or agents automatically register themselves into this table when they start and deregister themselves when they stop. In addition, they also update their status in the YFS_HEARTBEAT table on a regular basis. At any time, the heartbeat table has a record for every running server instances and integration server/agents.
The "Cache Clear Count" column in the System Management Console > Table Level Cache List screen provides statistics on the number of times the cache was cleared at the table level.
A JVM may not be able to deregister its entry from the YFS_HEARTBEAT table if it died abruptly. This could lead to stale entries that point to non-existent JVMs. You can clean up these stale entries by running the Health Monitor agent.