Determining When to Use Restart

Usually, you want to develop programs to take advantage of Application Engine restart capabilities. Programs that are good candidates for restart do a lot of preparation work initially, such as joining tables and loading data into temporary work tables. Also, you should consider restart capabilities for programs that might put data in an unstable state if they terminate abnormally during a run. As a general rule, restart is essential for programs that primarily do set-based processing.

However, you may want to disable restart if your program has one the following characteristics:

  • It is mainly row-by-row processing.

  • The overhead involved with Application Engine performing a checkpoint during the program run is not desirable.

  • The program commits after N iterations of a looping construct within a step, and the Select statement driving the loop is composed in such a way that if the program terminated and then started again it would ignore transactions that were already processed in the previous program run. In a sense, the program processes the restart internally: Application Engine treats each start of a program as a fresh start, instead of restarting a previous instance.

When developing for restart, consider the consequences if a program fails and you cannot restart the program. Given the commit structure that you defined for your Application Engine program, would your data remain in an usual state if a failure were to occur after any of the commits? Would it be easy to recover from such a case?

Using Restart at the Program Level

Application Engine automatically updates all state records. When an Application Engine program starts, it inserts a row in the state record for the assigned process instance. Then the system updates the state record whenever the program performs a commit to store changed values into the database. Finally, the system deletes the state record row upon successful completion of the application.

However, if the state record the program uses is a work record, you cannot make any database updates to the record. Consequently, if you restart the program, you might get unexpected results because the memory was lost when the program terminated. In fact, the system re-initializes any state records that are work records at each commit in order to ensure consistent behavior during a normal run and a restarted run. Therefore, you may need to make at least one of your state records a SQL table to contain values that must be retained across commits or in case of termination.

Finally, the other consideration for programming for restart at the program level is to check both the Application Engine Program Properties dialog box and PeopleSoft Configuration Manager to make sure the Disable Restart check box is not selected.

Using Restart at the Section Level

The section level property associated with restart is section type, which has the options Prepare Only and Critical Updates.

If a section only prepares data, as in selecting it, populating temporary tables, or updating temporary tables, then set the section type to Prepare Only. However, if the section updates permanent application tables in the database, then set the option to Critical Updates.

During runtime, when the system arrives at the first section set to Critical Updates, it sets the AE_CRITICAL_PHASE value in the AERUNCONTROL record to Y. Once set, the value of AE_CRITICAL_PHASE remains Y until the program completes successfully. When the program completes, the corresponding row in AERUNCONTROL is deleted. Therefore, a Prepare Only section following the Critical Updates section will not reset the AE_CRITICAL_PHASE value to N.

If your program terminates, the user can check the AE_CRITICAL_PHASE value. If it is Y, then the user knows that the section that failed is critical and that the program should be restarted to ensure data integrity. If AE_CRITICAL_PHASE is N, restarting may not be necessary; however, as a general rule you should restart even if AE_CRITICAL_PHASE is set to N.

Using Restart at the Step Level

In the Where clause of a Do Select action in your program, you should include conditions that reduce the answer set returned from the Select statement.

For example:

SELECT RECNAME, FIELDNAME
   FROM PS_AE_RECFIELD
   ORDER BY RECNAME, FIELDNAME

If you ran this Select statement as part of a Do Select action with Restartable selected as the Do Select type, the system might process some of the rows twice after a restart. Also, if you specified Reselect, the program could execute in an infinite loop because no code exists to reduce the answer set. However, if you modified the Select statement as follows, you could make it Restartable: 

SELECT RECNAME, FIELDNAME
FROM PS_AE_RECFIELD
WHERE RECNAME > %Bind(RECNAME)
OR (RECNAME = %Bind(RECNAME) AND FIELDNAME > %Bind(FIELDNAME))
ORDER BY RECNAME, FIELDNAME

You can convert a Do Select action that was coded for Restartable to Select/Fetch, but the opposite is not true.

The previous example shows the use of a key column to reduce the answer set. A key column can be convenient if your record has only one or two key fields; however, if your record has three or four keys, your SQL would become overly complex.

Instead of matching key fields, you could add a switch to the selected table and then have the processing of the called section modify the switch as it processes the row. In this example, your Select statement might look like this:

SELECT COLUMN1, COLUMN2, . . .
   FROM PS_TABLE1
   WHERE PROCESSING_SWITCH=’N’. . .