Persistence Management

By default, presentation logic is persistent with WebFOCUS Maintain. This means that when the application processes a Winform_Show command, a formatted HTML screen is returned to the user, and the procedure and processing agent wait, or persist, until the user invokes another submit through the Servlet to the running procedure. The Attach Manager in the server, using the cookie, reattaches the user to the waiting procedure and processing agent, and processing continues. In this way, the waiting procedure and processing agent retain the user context between the different forms or screens of the application user experience. User context means the value of variables and stacks of an application, position in a database, and state of the transaction at any given time.

When a Maintain procedure CALLs or EXECs another procedure on a different server, by default both the connection and remote procedure remain persistent. The calling Maintain waits for a response from the called procedure and continues processing after a completed response. The called procedure is complete when it reaches the EXIT command and returns control to the calling procedure. No communications disconnect is issued. The called procedure is instantly recallable using the persistent connection and the memory resident status of the procedure.

By using the keyword DROP in the CALL or EXEC statement, the connection can be dropped between the calling and the remote called or execed procedure after control has been returned to the calling procedure. In this way, a large number of presentation logic procedures can share a smaller number of database logic procedures on a DBMS platform server.

In certain environments, the cost of new connects or disconnects between servers can be expensive or prohibitive. In these environments and server configurations, the strategy may be to keep the sub-server connected, since the calling server is set to pool its connections to the called server.

Actual usage must be evaluated. For example, do users spend longer periods on certain screens, or do they leave certain screens running when they go to lunch? The possibility or impact of these items must be evaluated before determining the persistence characteristics of an application.

Although a called procedure that has not been dropped maintains connection persistence, by default, the called procedure does not maintain the users context between calls. When the called procedure reaches the EXIT command, it terminates and returns control to the calling procedure. All application variables and stacks, database positions, or transactions in the called procedure are lost. The next time the remote procedure is called, all variables, stacks, and database positions must be reestablished.

To retain the user context in a called procedure, you must add the syntax GOTO END KEEP in a logical place in the called procedure to insure its execution before exiting. When this step is implemented, the called procedure will retain the values in variables and stacks, and retain database positions until it is called again. This approach is often used when the application requires the scrolling of many database records. The user can request more records, and the application retrieves more records, by using the next database position retained by the called procedures context (rather than by retrieving a large answer set prior to a user request for more records). Maintaining user context in the called procedure is also the only way to provide DBMS record locking for those infrequent applications that require this level of transaction control.

In summary, by using the keyword DROP, the application developer is able to control the connection persistence of the CALL or EXEC logic section of the application to best optimize the nature of the application, the available resources, and the actual usage of the application. By using GOTO END KEEP, the developer can control the context persistence of the called procedure.

Note: When evaluating the DROP strategy with any application, the key determining factors are often the details of the actual user behavior, not the code performance or machine or network resource restraints.