ZSYNC (legacy command) (ObjectScript)
|pc||Optional — A postconditional expression.|
This page describes the legacy ZSYNC command. The ZSYNC command is considered legacy as of Caché 2010.2 because its only use is to support the obsolete Distributed Cache Protocol (DCP). ZSYNC should not be used in new programming. It is described here solely for compatibility with legacy applications.
ZSYNC synchronizes and forces the conclusion of all network transactions for the current job. You can also use ZSYNC in non-networked applications that might later be run in a networked environment. Simply place it at the end of each complete transaction.
ZSYNC ensures that if multiple updates to a global (SET or KILL operations) are synchronized by LOCK operations, that READs of that global return those updates in the correct order. It does this by synchronizing delock operations across a network. When a delock occurs on an existing lock, any updates to a global that have been initiated (on any system) before the delock is initiated will be completed before the delock completes.
ZSYNC is used with Distributed Cache Protocol (DCP). ZSYNC performs no operation on a system configured for an Enterprise Cache Protocol (ECP) data server. ECP uses synchronous-commit transactions to perform similar synchronization functionality. Because ECP is commonly used with Caché server system networks and clusters, your use of ZSYNC may be limited. For further details on ECP, see the Caché Distributed Data Management Guide.
An optional postconditional expression. Caché executes the command if the postconditional expression is true (evaluates to a nonzero numeric value). Caché does not execute the command if the postconditional expression is false (evaluates to zero). For further details, refer to Command Postconditional Expressions in Using Caché ObjectScript.
ZSYNC Guarantees Return of Asynchronous Errors
Depending on the operation requested, network errors are reported at different times. Errors for synchronous operations, such as LOCK, $GET, $ORDER and $QUERY, are reported immediately through the normal error trap on the command that performed the error.
Errors for asynchronous operations, such as SET and KILL, may be reported either immediately or after a delay.
Delayed errors return as a result of buffered asynchronous operations. When a job invokes either SET or KILL, processing can continue on the client while the operation on the server completes. In this case, a special interrupt trap may occur sometime later in the program. The error code returned is identical to the error that originally occurred on the server.
When you use the ZSYNC command to synchronize the activity of clients and servers, you force the return of any asynchronous errors. That is to say, all global errors return to the job before the ZSYNC command completes.
You can control whether asynchronous errors can interrupt a process on a per-process basis using the AsynchError()Opens in a new tab method of the %SYSTEM.ProcessOpens in a new tab class. The system-wide default behavior can be established by setting the AsynchErrorOpens in a new tab property of the Config.MiscellaneousOpens in a new tab class.
ZSYNC Guarantees Transaction Completion
The ZSYNC command lets applications synchronize activity on network servers. Executing this command forces the completion of all network transactions for this job. Do not use this command at the end of an update transaction that completes the filing of all global nodes on all servers, because it forces any delayed errors to be returned. In other words, all global errors are delivered to the job before the ZSYNC command completes.
Using ObjectScript for Transaction Processing in Using Caché ObjectScript