timeout

A timeout occurs after an interval of inactivity. When a timeout occurs, various system resources are conserved to make them available to others.

PRPC enforces various timeout intervals as follows:

• Access Group timeouts, also called authentication timeouts, are established in the Settings tab of the access group form. This setting applies only to interactive ( browser-based) users. The system may challenge users who have not sent input to the server during a period, forcing them to reenter an Operator ID and password.
• Requestor timeouts, based on the values in the timeout/browser and timeout/application entry of the prconfig.xml file or Dynamic System Settings, apply to interactive users and service requestors respectively. If no processing is initiated during this interval, the requestor session ends or is passivated. See Understanding passivation and requestor timeouts. The default timeout for browser sessions is 1 hour (3600 seconds). For services, the default is 600 seconds. You can override these defaults with other values (in seconds) by adding a configuration setting named prconfig/timeout/browser/default and a value of 1800 (for thirty minutes). See How to create or update a prconfig setting.
• Portal timeouts, based on two optional time values on the Options tab of portal rules, providing a warning and session expiration interval for traditional portals. This field on the portal rule does not affect users accessing the server with composite portals. BROUB 4/4/11
• Lock timeouts are determined by a setting on the System form (Data-Admin-System class). Locks held for longer than this interval are marked as "soft" and may be forcibly released, even when the requestor session is active and processing. (Locks held for long intervals may indicate looping or design problems.)
• Dynamic select operations and autocomplete operations time out after a few seconds.
• Clipboard pages created by Data Page rules expire and require rebuilding after 24 hours, or another timeout period determined on the Advanced tab.
• JavaScript code, CSS style sheets, and image files (JPG, GIF, PNG, SWF) sent by PRPC to a browser session normally are retained in the browser cache for 24 hours.

Saving requestors after access group, portal, and requestor timeouts

When a requestor session ends because an access group, portal, or requestor timeout setting was reached rather than by a logging off, the results depend on the value of the Initialization/PersistUNP setting in the prconfig.xml file or Dynamic System Setting. The system can passivate (save) the requestor's state and clipboard, allowing the processing to resume later. The system may challenge users who have not sent input during a period, forcing them to reenter an Operator ID and password.

Timeouts and custom authentication

If you implement authentication through an Authentication Service feature, you can replace the fixed authentication timeout interval with an algorithm of your choosing, defined through an activity.

Displaying a timeout alert

PRPC provides a standard section, pxSessionTimer, that you can include in a portal harness and configure by setting the TimeOutTime and TimeOutWarning properties. You also need to set the RedirectOnTimeout When rule to True to activate not just the alert, but the correct behavior (ending the session and logging the user out) when the value of TimeOutTime is exceeded.

When pxSessionTimer is included in a portal harness, and the value set in TimeOutWarning is exceeded, a modal dialog appears to alert the user that timeout will occur due to inactivity. A countdown display shows the time until timeout. The user can reset the clock by clicking an OK button included in the section.

	lock, prconfig.xml file
	Understanding passivation and requestor timeouts About Access Groups About Authentication Service data instances About the System data instance

Definitions