Refresh strategy for data pages
After you determine how long the data on a data page (referred to as a "declare page" in versions prior to Pega 7) remains fresh, enter that information in the Refresh strategy section of a data page form.
To avoid keeping data pages indefinitely, Pega 7 periodically checks all Node-scope data pages on the clipboard to find data pages that have not been referenced for 24 hours or more. If a data page has not been accessed for that time interval, the page is automatically deleted.
Refer to the appropriate section below for version-specific information on performing this task:
- Data pages (Pega 7 and later)
- Declare pages (PRPC versions 5.1 through 6.3 SP2)
Data pages
The connector, report definition, or other load mechanism serving as the data source for the data page runs the first time that any requestor within the scope (either Node or Thread) references the page (such as when accessing the value of a property, or when testing whether a property is present).
Optionally, on the data page's Load Management tab, you can define criteria (using the Do not reload when and Reload if older than fields) that can cause the system to delete instances of the data page on the clipboard and rerun the load mechanism. This action creates the page or pages again with possibly fresher contents when subsequently referenced (such as after the first load).
The Refresh strategy section on the Load Management tab of a data page form
All three fields on this tab are optional:
| Field | Description |
|---|---|
| Reload once per interaction | Select this check box to cause the system to refresh exactly once per user interaction. This option is available only for rules with Page scope set to "Thread" or "Requestor". When this check box is selected, at run time the system ignores any values in the Refresh if older than and Page is fresh when fields. For Thread-scope pages, determine the refresh strategy carefully, especially if your refresh operation is costly in terms of elapsed time or use of system resources. This involves a trade-off of possibly stale data versus additional processing. For example, refreshing upon each interaction might introduce avoidable extra processing if once-per-hour is good enough. However, in a high-frequency access situation, refreshing once per minute can be less often (and less costly) than once per interaction. |
| Do not reload when | Identify the When record to be evaluated when a requestor accesses a page with a Page scope of "Thread" or "Requestor". If the When rule evaluates to false, then the page contents are refreshed. However, the page is never refreshed more than once per user interaction. |
| Reload if older than | Optional: Enter the amount of time in days, hours, minutes, and seconds, after which the data page is considered expired. The timer starts when the page is first loaded, not from the time of last access. The data page is refreshed only when another access request is made after the expiration time, and is never refreshed more than once per user interaction.
|
Declare pages
Three fields control how declare pages are refreshed:
Refresh if older than
This field allows the developer to limit the "age" of the information on the declare page. Each time a declare page is accessed, the system checks this field to determine whether the page has expired. If the page has existed longer than the specified value, then the Load Activity re-creates the page.
This field applies to both Node- and Thread- scope pages.
Refresh page when (Thread scope only)
For Thread scope pages, if you prefer to create a When rule to specify when the page should be reloaded, create the When rule and reference it into this field (on the Definition tab).
In this case, every time that this declare page is accessed at run time, the system evaluates the When rule.
- If the When rule evaluates to true, the page is considered fresh.
- If the When rule returns false, the page is considered stale, and the Load Activity creates a new page.
For Thread scope rules, both the Refresh if older than and the Refresh page when fields are available. Both are evaluated when the system assesses whether the declare page instance is stale. If either field’s value indicates that the page is stale, the page is refreshed.
The Refresh page when field is not available for Node scope. This is because it is important to reload the system-wide pages as infrequently as possible while still keeping them fresh, and to evaluate declare page instances as few times as possible. For Thread scopes, When evaluations are for one requestor only.
At the Node level, these evaluations or refreshes can be caused by hundreds or thousands of users, so excess reloading has a more visible effect on performance. Therefore, the only refresh trigger for the Node level is the Refresh if older than field.
Allow idle timeout
The Refresh fields on the Definition tab are optional. However, if time-outs are not defined, declare Pages remain on the clipboard indefinitely, taking up memory. Additionally, even if a time-out is specified in a declare page definition, if that page is not called for a number of days, it is not reloaded, and also stays on the clipboard taking up memory.
To avoid this situation, an additional time-out is used to remove declare pages. The master agent looks at all the Node-scope declare pages on the clipboard to see if any have not been referenced in more than 24 hours. If a declare page instance has not been invoked in that time, it is deleted from the clipboard. Selecting the Allow idle timeout check box on the Advanced tab enables this functionality.
By default, idle time-outs are enabled and set to 24 hours. However, note that the 24-hour period is a “fallback” default. If you specify a time-out in either of the Refresh fields of the declare page rule, the system uses that time-out, even if it is longer than 24 hours.
To change the background idle time-out interval, add the DefaultIdleTimeSeconds setting to the prconfig.xml file:
<env name="DeclarePages/DefaultIdleTimeSeconds" value="86400" />
This entry specifies the amount of time in seconds between idle time-out checks.
Setting the DefaultIdleTimeSeconds value too low can cause slower performance, causing declare pages to expire and be deleted too quickly, and forcing the system to frequently rerun the load activity to re-create them whenever they are next referenced.
Additionally, time-outs only delete declare pages, and do not refresh them. If the page is later referenced again, the load activity runs at that time to re-create the page.