Server and Client Execution Restrictions

The following restrictions apply when using the serverExecution or clientExecution method option.

• You cannot specify these method options on primitive type methods (for example, a String or Integer method). Methods defined on primitive types are always executed in the node of the calling method.

• Persistent transactions must be total client transactions or total server transactions; that is, any beginTransaction and commitTransaction pair of instructions must be done while executing on the client (without executing an updating server method), or while executing on the server (without the execution of updating client methods). This restriction applies also to the beginLoad and endLoad and the beginLock and endLock instruction pairs. Transient transactions (for shared transient objects) do not have this restriction.

• Persistent transactions must be started, performed, and finalized on a single node (that is, a client node or a server node). All of the update operations of the transaction must occur in the same node that started the transaction. Applications should not attempt to access persistent objects that have been updated but not yet committed on the other node. The updates are usually not visible on the other node. A 1276 exception (Potential cache inconsistency) may be raised if this is attempted.

• You cannot debug server execution methods nor can a server method invoke a graphical user interface (GUI) method.

• You can access all GUI properties and methods (which are marked as clientExecution methods) from a server method except for anything that brings up a modal-type dialog (that is, the common dialog class methods and the Application::msgBox, Form::showModal, and Form::popupMenu methods). The other exceptions to this are the Application class doWindowEvents, checkPictureFile, and loadPicture methods, which are executed relative to the server.