Long Running Query / Procedure Causes Web Deployed Forms to Disconnect [ID 271611.1]
The end user may see the errors FRM-92100 or FRM-92101 or FRM-92102 e.g.

FRM-92101: A failure has occured on the Server.
You will need to reestablish your session.

Java Exception.
oracle.forms.netConnectionException: Forms session [30] aborted unable to communicate with runtime process.

Making changes to the following settings makes no difference:

- the FORMSxx_TIMEOUT environment variable and the applet parameter 'heartbeat'
- the jServ or OC4J session.timeout / session-timeout parameter
- the HTTP Server timeout directive


The Forms Runtime process on the middle tier is awaiting the outcome of what is being processed by the database. The Runtime process fails, however, to communicate to the client that it is in a waiting state. Eventually either the underlying network or client browser or Oracle HTTP Server / Servlet settings cause the connection to be timed out and thus disconnected.

To address this issue a new Forms Listener Servlet parameter called maxBlockTime was introduced. This fix / enhancement works as follows:

1) The Forms Applet client makes a request to the database to execute a long running operation

2) The Forms Listener Servlet forwards the request to the forms runtime process and waits on the socket for reply for the period specified for the maxBlockTime parameter e.g. 1 second

3) As the database operation is not going to finish in one second the socket times out causing an exception.

4) The Forms Listener Servlet handles the exception and sends a special type of response to the client called "RESPONSE_PENDING" indicating that the forms runtime process will not be interrupted (or abandoned), rather it will be allowed to continue it's interaction with the database

5) This response is interpreted by the client applet as though "The response for the request sent is not yet ready, please try after X milliseconds.".

6) The client applet then waits for X milliseconds to pass before sending out a "Reminder" message asking the Forms Listener Servlet for an update.

7) The ListenerServlet recognizes the "reminder request" and will try to read from the forms runtime process again.

8) Now again if the database operation takes more than the maxBlockTime value the socket times out again and an exception would occur, followed by the series of events from step 4. This loop continues until the database operation completes

9) When the database operation completes upon the response / outcome is sent back to the client rather than another RESPONSE_PENDING message.

Therefore with the maxBlockTime parameter in place the Forms applet is no longer disconnected when the end user chooses to execute a long running query / procedure / function on the database.


The new Forms Listener Servlet parameter 'maxBlockTime' was introduced in the following patchsets :

- Forms  and higher
- Forms  and higher
- Forms 9.0.4.x
- Forms 10.1.2.x

The parameter value is in milliseconds (default value is 1000 i.e 1 second) and is set in:

Oracle 9iAS Rel 1 Forms Services (Forms 6i):



Oracle 9iAS Rel 2 Forms Services / Oracle Application Server 10g (9.0.4) Forms Services




Oracle AS 10.1.2.x



Note: the parameter 'maxBlockTime' will only work for Forms 6i if deploying forms over the web using the Forms Listener Servlet, rather than the original Forms Server, architecture.

Niciun comentariu:

Trimiteți un comentariu