Setting Synchronization Point Options
- WAIT
- If a resynchronization is required, control is not returned to your application until resynchronization completes.
- BACKOUT
- If a protocol violation (notification of an inconsistency) is received from the sync point initiator while in prepared state (ready to commit), CMS will roll back the changes to the work unit(s) specified for the sync point.
- SYNC
- On certain requests the virtual machine will remain in a wait state until the request completes.
The choices you need to make depend on your application and the installation where it will run. The following discussion should help you understand what each choice of options means to your program.
- Recovery was successful as indicated by the return code (either a commit or roll back was completed), or
- A commit or rollback was performed, but the state may not be consistent due to a unilateral decision (possibly operator intervention) on the part of one or more resources to commit or roll back contrary to the global (CRR) decision.
If your application must operate in an environment that dictates a different course of action than that just described (for example, delays of more than a few seconds are intolerable), you can set the NOWAIT option. This option means that resynchronization will still be tried, but if it is not successful on that first try, control is returned to your application with a resynchronization-in-progress reason code. This could be useful if your application processes transactions in an interactive environment. Your program can continue other processing (unless the system goes down), and the resynchronization will complete later, possibly even after your application ends. Alternatively, if the success or failure of the transaction in resynchronization could affect future transactions, your program could terminate.
In any case, you should consult your system administrator so you can be aware of computer center procedures for such things as recovery and operator intervention.
BACKOUT/COMMIT: If a protocol violation is received from the initiator (your protected conversation partner) of the synchronization point while in prepared state, CMS rolls back the changes to the specified work unit(s) by default. This is an attempt to ensure that recovery can be achieved quickly and reliably. It is generally safer to assume the worst in transaction processing. If this is not satisfactory for your application's environment, you can set the COMMIT option so that an attempt will be made to commit the changes in the event of a protocol violation on the part of the initiator of the sync point.
SYNC/ASYNC: The (default) SYNC option allows the SPM to communicate synchronously with a protected resource when it is more efficient to do so. Ordinarily, when the SPM needs to communicate with more than one protected resource, it does so asynchronously. There are times, however, such as when reading from one resource and writing to another, when the SPM is only communicating with one resource at a time, even though more than one resource is involved. If ASYNC is set, the SPM is forced to communicate asynchronously with that one resource. The SYNC setting allows the SPM to switch to synchronous communications when that is the better choice.
If your application performs multitasking, you should set the ASYNC option. This allows CMS to regain control immediately and to call DMSCWAIT (CRR Wait) for any requests to the CRR recovery server. Your application can then intercept the call to DMSCWAIT and dispatch another task (which will be using a different work unit ID). You must provide a replacement for DMSCWAIT to handle the waiting. See Writing a CRR Wait Routine for Multiuser Server Applications.
ALL/SINGLE: Should you decide to set any of the sync point options, you can also specify whether you want the settings to apply to all current and future work units or only to a specific work unit.