Question & Answer
Question
In IBM® Content Manager OnDemand server V7.1.2.8, a new feature was introduced that allowed OnDemand cache expiration to be changed dynamically. In previous versions, a load expired based on the Cache Document Data for X Days configuration value at the time of the load. This meant that only future loads would be affected by a change to the cache expiration setting. Past loads would expire based on the cache expiration value at the time of the load. If I wish to change the cache expiration for data already loaded into OnDemand, will upgrading to V7.1.2.8 or later be the correct solution?
Cause
From the OnDemand server V7.1.2.8 readme.txt:
"Expiration dates for data are now dynamic and based off the current expiration period in the application group and not tied to the expiration date set at load time any longer. This means it is possible to increase or decrease the amount of time data is kept in the OnDemand cache by simply changing the expiration period in the application group. The ARSMAINT program will now calculate expiration dynamically during processing."
Answer
The answer depends on the history of changes to the Cache Document Data for X Days setting in the application group. To understand why previous changes affect the answer, how this new feature is implemented in OnDemand must be understood.
In OnDemand server V7.1.2.8 or later, a running cache delta is introduced to track changes to the Cache Document Data for X Days setting. The delta value is what allows OnDemand to change cache expiration retroactively. An initial delta value of 0 is associated with each application group after upgrading to OnDemand server V7.1.2.8 or later.
An example demonstrating how the delta is used:
- OnDemand server is upgraded to V7.1.2.8 or later.
- An application group has Cache Document Data for X Days set to 30.
- The cache delta for the application group has an initial value of 0.
- Cache Document Data for X Days is changed from 30 to 90 days.
- The cache delta is now 0 + 60 = 60.
- Cache Document Data for X Days is changed from 90 to 40 days.
- The cache delta is now 60 - 50 = 10.
- When cache expiration (arsmaint -c) is run, the delta is added to the expiration date from cache.
Previous to V7.1.2.8, the expiration date of a cache object was stored solely in the naming of the cache directory where the object resided. The directory name translated into an internal date. This date reflected when the contents qualified for expiration from cache; the maximum Segment date from the object (collected during load time) plus the Cache Document Data for X Days setting at the time of the load.
To conform with this design, the original Cache Document Data for X Days value when OnDemand is upgraded to V7.1.2.8 (and later) is retained. This is accomplished by subtracting the delta from the Cache Document Data for X Days value. When arsmaint -c is run, the cache delta and expiration date from the cache directory name are read and added together, forming the true expiration date. This is how changes to the cache expiration setting are made retroactive.
An example demonstrating the dynamic cache expiration feature:
- After upgrading to V7.1.2.8, an application group has Cache Document Data for X Days set to 30 days.
- The cache delta for the application group has an initial value of 0.
- A load, with a maximum Segment date of 01/01/10, is ingested into the application group.
- The cache directory name will reflect the expiration date of the cache objects as 01/01/10 + 30 days - 0 delta = 01/31/10.
- The application group is then changed to retain cache from 30 to 90 days.
- The cache delta for this application group is now 0 + 60 = 60.
- Cache expiration (arsmaint -c) is executed.
- Arsmaint will take the date from the cache directory name (01/31/10) add the delta (60 days) and expire the contents on 01/31/10 + 60 days = 04/01/10.
Now take into account the following example, where an undesired cache expiration might occur.
- OnDemand server is running V7.1.2.7 or earlier.
- Cache Document Data for X Days is set to 30 days.
- Dynamic cache expiration did not exist at this earlier version, so a cache delta does not exist.
- Document data loaded into the application group.
- Cache Document Data for X Days is changed to 90 days.
- More document data loaded into the application group.
- OnDemand server upgraded to V7.1.2.8 or later.
- The cache delta is set at an initial value of 0.
- Cache expiration (arsmaint -c) is executed.
- Data loaded in step 4 will expire in 30 + 0 = 30 days.
- Data loaded in step 6 will expire in 90 + 0 = 90 days.
- Cache Document Data for X Days is changed from 90 to 150 days.
- The cache delta is now 0 + 60 = 60.
- Data loaded in step 4 will expire in 30 + 60 = 90 days.
- Data loaded in step 6 will expire in 90 + 60 = 150 days.
The example demonstrates that even though OnDemand server is running V7.1.2.8 or later and Cache Document Data for X Days is set to 90 or even 150 days, previously loaded data might expire earlier. This is because the cache delta can only track changes made to the cache expiration setting after an upgrade to V7.1.2.8 or later.
The solution in this case would be to reload this older data, so the current Cache Document Data for X Days and cache delta values are used. The alternative would be to engage IBM Services to alter OnDemand cache to reflect the desired expiration. Altering OnDemand cache manually is otherwise not supported.
Related Information
Was this topic helpful?
Document Information
Modified date:
23 June 2018
UID
swg21409710