Skip to main content
Broadpin

Timeouts in Oracle Forms

This blog post was originally published on 21 July 2020 by PITSS, which is now Broadpin.

By default, Oracle Forms is not configured to have sessions timeout after a session has been idle for a specific period of time. However, it can be possible to either configure timeouts in Oracle Forms or to have Forms sessions time out due to outside factors.

In Forms 12c, Oracle Forms has three different parameters available for configuring timeouts:

  • heartBeat – Indicates the frequency which the client sends a packet to the server to indicate that it is still up and running

    • Defined in: $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config/formsweb.cfg

    • Default value (if not set): 2 (minutes)

    • Minimum allowed value: None

    • Maximum allowed value: None

  • FORMS_TIMEOUT – Indicates the amount of time (in minutes) before a Forms session is terminated when there is no client communication with the server. Such communication occurs when either the user is doing something in the app or from the heartbeat when the user is not using the form (the session is idle).

    • Defined in: $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config/<ENV_FILE>.env

    • Default value (if not set): 15 (minutes)

    • Minimum allowed value: 3 (minutes)

    • Maximum allowed value: 1440 (minutes)

      • NOTE: Oracle does not recommend setting FORMS_TIMEOUT greater than 15 minutes.

  • Session-Timeout – Indicates the number of minutes elapsed for timing out a Forms session.

    • Defined in: $DOMAIN_HOME/config/fmwconfig/deployment-plans/formsapp/12.2.1

    • Default value (if not set): 60 (minutes)

For no timeout to occur, the heartBeat must be set to a value less than both FORMS_TIMEOUT and Session-Timeout. The reason is that when a Forms session is idle, a heartbeat is sent from the client to send a signal to the server to keep the session alive and not timeout. A timeout from the Forms side will only occur if the time between when the session became idle and either FORMS_TIMEOUT or Session-Timeout is reached before either a session becomes active again by user interaction or by a heartbeat. With the default settings indicated above, the heartbeat is set to a value less than both FORMS_TIMEOUT and Session-Timeout. As a result, no timeout will occur unless timeout settings are manually configured.

Configuring Timeout in Oracle Forms

If you wish to configure a timeout feature in Oracle Forms, the recommended option is to either create a Forms Timeout JavaBean or (new to 12c) is to create a system event, SYSTEM_CLIENT_IDLE. Unlike the Timeout Bean, there are less limitations with the system event. The full solution may be found in https://support.oracle.com/epmos/faces/DocumentDisplay?id=2114912.1, but the solution involves creating an alert, CLIENT_IDLE_ALERT, then creating a number type called event_value, a button trigger, an event called CLIENT_IDLE with the “Event Type” property of “System Client-Idle”, and a WHEN-EVENT-RAISED trigger. Last, run the form, set a valid timeout entry value into the EVENT_VALUE, press the button to start the timeout, and then the CLIENT_IDLE event will take place as soon as the timeout set in the EVENT_VALUE is reached. Once it has, the alert will then pop up.

NOTE: If any model/blocking window is displayed, idle code will not fire until after the blocking condition is released. If you need it to behave differently, a custom JavaBean will need to be developed.

Although it is not recommended by Oracle, you may also configure timeout by setting the heartBeat parameter to be greater than FORMS_TIMEOUT. For example, if FORMS_TIMEOUT is set to 15 (minutes) in your ENV file and you set the heartBeat to 16 (minutes) in formsweb.cfg, a heartbeat will not be sent to the server from the idle client until the heartBeat limit (16 minutes in this example) is reached. Thus, the FORMS_TIMEOUT limit will be reached, and idle sessions will then see a FRM-93652 error after 15 minutes or however long the FORMS_TIMEOUT variable is set.

Another option which is not recommended by Oracle is to set the heartBeat greater than Session-Timeout (in plan.xml) but not necessarily greater than FORMS_TIMEOUT. The same timeout situation will happen, but an FRM-92102 error will appear instead.

FRM-91230 – Fatal Error in Runtime Process: Timeout on Connection to Java Client

Sometimes Forms sessions may be kicked out or timed out due to outside factors such as database timeouts, network issues, server issues (on the OS level), or load balancers. In the front end, users may either see a Forms session or JNLP window exit out or crash with an error such as FRM-93652. One of the first places to look for any Forms-related errors is in formsapp-diagnostic.log located in $DOMAIN_HOME/servers/WLS_FORMS/logs. In the logs, you may notice periodic errors such as FRM-91230. This usually indicates that the user lost connection to the Forms runtime process due to a termination. For Oracle Forms 12c, this may be seen due to the following reasons:

1. Users closed the browser without exiting the Oracle Forms application gracefully

a. This can be quite common. The only way to prevent this is to either educate the users to gracefully exit the application before closing the browser whenever possible (it may be unavoidable if the browser itself crashes for any reason) or to program the forms to alert the user to gracefully close the form first. If you are using Java Web Start or FSAL, users will also be left apt to close the application improperly.

2. Heartbeat is greater than FORMS_TIMEOUT

a. Oracle does not recommend this approach for configuring timeouts. See the Configuring Timeout in Oracle Forms section for details on recommended approaches. If you do not configure timeouts manually in Oracle Forms, the heartBeat parameter will be less than FORMS_TIMEOUT.

3. Inappropriate timers in forms

a. Timers (if configured) should have as short duration and low frequency as possible. If you need to utilize timers, Oracle recommends configuring JavaBeans for this.

4. Network issues

Sources