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

Process Commander enforces various timeout intervals as follows:

• Access Group timeouts, established in the Settings tab of the access group form, apply to browser-based users only. The system may challenge users who have not sent input 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 elements of the prconfig.xml file, 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). For example:
  <env name='timeout/browser" value="1800" />
• Portal timeouts, based on two optional time values on the Options tab of portal rules, providing a warning and session expiration interval.
• 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 Declare Pages 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 Process Commander 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. 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.

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

Definitions — T