Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Refresh strategy for data pages

Updated on January 6, 2020

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.

This process is optional. If there is no need to refresh the data periodically, you can leave this field blank.

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

This section applies to Pega 7.

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).

Refresh strategy section

The Refresh strategy section on the Load Management tab of a data page form

All three fields on this tab are optional:

FieldDescription
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.
For example, assume a reload time of 10 minutes:

  • The data page is accessed for the first time at 1200. The data page is loaded because this is the first access.
  • The data page is accessed for the second time at 1208. The data page is not loaded. The existing copy is returned.The data page is accessed for the third time at 1211.
  • The data page is reloaded because the time from the last reload at 1200 exceeds the Reload if older than setting of 10 minutes.

Declare pages

This section applies to PRPC versions 5.1 through 6.3 SP1.

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.

The background idle time-out applies only to Node-scope only. Thread-scope declare pages persist in the system until the requestor session that created them ends.

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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us