Related information
Data Page rules
|
|
The Load Management tab provides several controls for managing the instances of this data page on the clipboard.
Note: The only option displayed for editable data pages is Clear Data Page. You cannot configure any other load management controls; they display for read-only pages only.
Click Clear Data Page to remove from the clipboard all instances of this read-only or editable data page. If the page is parameterized, you have an option to delete all instances or only those with specific parameter values.
The connector, report definition, or other load mechanism executes the first time any requestor within the scope (Node or Thread) references the red-only data page (such as to access the value of a property, or to test whether a property is present).
Optionally, you can define one or two criteria (Do not reload when and Reload if older than) that can cause the system to delete data pages from the clipboard and call the data page again, creating the clipboard page or pages again with possibly fresher contents when subsequently referenced (such as after the first load).
These two criteria are ignored if the Limit to a single data page check box is selected. The system then deletes and reloads the page on each interaction with the server.
Field |
Description |
| Reload once per interaction |
Select the check box to cause the system to refresh the page exactly once per user interaction. This option is available only for data pages with Page Scope set to Note: 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 may 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 so less costly) than once per interaction. |
| Do not reload when | Optional. Identify the When rule to be evaluated when a requestor accesses a page with a Page Scope of Thread or Requestor.If the When rule evaluates to false, the page contents are refreshed. However, the page is never refreshed more than once per user interaction. To find this rule at runtime, rule resolution uses the class in the Page Class field as the Applies To class, and uses the ruleset list of the requestor. |
| Reload if older than |
Optional. Enter positive integers in one or more of these fields to define an expiration time interval in days, hours, minutes, and seconds. The timer starts when the page is first loaded. The page is refreshed only when another access request is made after the expiration time. The page is never refreshed more than once per user interaction. |
Note: Pega 7 Platform supports refreshing node-level data pages. If you refresh an expired data page using any of the following methods, the system synchronizes all nodes by refreshing the data page on all nodes in the system:
There may be a delay of up to five minutes for a system-wide refresh to complete.
For read-only data pages, select the Limit to a single data page check box to prevent creating multiple instances of the data page on the clipboard. Once an instance of the data page is on the clipboard, each new reference to the data page overwrites the instance with the data related to the new reference.
Select the Clear pages after non-use check box to force the system to delete the clipboard instances of the data page after an interval passes with no access. Subsequent attempts by a requestor to access the data pages cause the pages to reload.
This setting has different effects depending on the scope of the data page:
You can change the timeout period from 24 hours (86,400 seconds) to a larger or smaller value by adding a setting to the prconfig.xml file in the following format:
<env name="DeclarePages/DefaultIdleTimeSeconds" value="nnnnn" />
where nnnnn is in seconds.
Note: As an alternative to the prconfig.xml file, you can use Dynamic System Settings to configure your application.
See How to create or update a prconfig setting.
By default, Pega 7 Platform can maintain 1000 read-only unique instances of a read-only data page per thread. You can change this value by editing the dynamic system setting datapages/mrucapacity.
There are different data page instance containers for the thread, requestor, and node level. Each user can have both requestor-level and thread-level data pages up to the limit established. Additionally, each node can have any number of requestors, and each requestor can have many threads.
For each container, if the number of instances of a data page reaches 60% of the established limit, the system begins deleting older instances. If the number reaches the established limit, the system deletes all data page instances that were last accessed more than ten minutes previously for that container.
At that time, if the number of instances of the data page still exceeds the set limit, the system tolerates an overload up to 125% of the established limit. If the number exceeds that overload number, the system deletes instances (regardless of when they were last accessed) until the number of entries in the cache is below the set limit.
The data page creates new instances as needed to respond to references and to replace the deleted instances.
For more on data page management, see PDN article, How PRPC manages data pages.