Data Page rules  Using the Load Management tab
About  New  Definition  Load Management  Parameters  Pages & Classes  Usage  History  More...

The Load Management tab provides several controls for managing the instances of this data page on the clipboard.

Page Management

Click Clear Data Page to remove from the clipboard all read-only instances of this data page. If the page is parameterized, you have an option to delete all instances or only those with specific parameter values.

Refresh Strategy

The connector, report definition (or other load mechanism) executes the first time any requestor within the scope (Node or Thread) references the 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 relload 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 (i.e. after the first load).

These two criteria are ignored if the Limit to a single data page check box is checked. The system then deletes and reloads the page on each interaction with the server.

Field	Description
Reload once per interaction	Check 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 Thread or Requestor. When checked, at runtime the system ignores any values in the Reload if older than and Do not reload 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 may introduce avoidable extra processing if once-per-hour is good enough. But in a high-frequency access situation, refreshing once per minute may 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 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. If not blank, any attempt by a requestor to access the page after a period of no accesses equal to or greater than the timeout causes the system to refresh the page. However, the page is never refreshed more than once per user interaction.

Note: PRPC 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:

• Use Page-Remove in an activity
• Click the Clear Data Page button on the Load Management tab of the Data Page rule form, as noted above
• When you click the run button for a data page, on the dialog that appears check the check box to clear existing instances of the data page

There may be a delay of up to five minutes for a system-wide refresh to complete.

Page Limits

For read-only data pages, check 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.

Check 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:

• Thread scope -- This setting has no effect.
• Requestor scope -- This setting applies to both editable and read-only data page instances. The system creates a requestor scoped instance when any thread refers to the data page and other threads can also reference the same data page instance. If the check box is checked, the data page instance is removed when there are no more threads referring to it.
• Node scope -- This setting applies to read-only data pages. If the check box is checked, the system checks the "Reload if older than" fields on the Load Management tab of the data page rule. If the fields are blank, the system uses the value of the dynamic system setting DeclarePages/DefaultIdleTimeSeconds, which is set by default to 86400 seconds, or one day.

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.

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.

Management of data page instances

By default, PRPC can maintain 1000 read-only unique instances of a 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. Further, 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.

If, after that step, 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 (irrespective 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 the PDN article, How PRPC manages data pages.

About data pages
Help Home