Jade Object Manager Distributed Processing

The Jade Object Manager implements object-oriented and distributed processing functionality.

The distributed processing components of the Jade Object Manager, listed in the following table, are the environmental objects maintained automatically by the Jade Object Manager.

Component	Description
system	A single object for a specific database. It contains a dictionary of the nodes that are currently signed on to the server node.
node	One node object exists for each logical workstation connected to the server node workstation. There is one fixed server node, and none, one, or many client nodes. A node represents a workstation that hosts the execution of one or several processes, and it contains a dictionary of the processes currently active in the node.
	A node object is created for each Jade executable program that is running; that is, a workstation that is running two Jade applications has two node objects, or logical workstation connections to the server.
process	One process object exists for every sign-on operation performed on a specific node. There is always a system process on every node, created automatically every time a node is initialized. This process is used for internal housekeeping of the node.

You can access these system-provided objects to assist in process distribution, by using the jomGetExecInstances Application Program Interface (API). For details, see "Getting Execution Instances", in Chapter 3.

The system-provided objects are created as instances of special classes: the System, Node, and Process classes. The instances of these classes correspond to the system, node, and process Jade system variables (Jade language reserved words), which are defined from the point of view of the method that uses them. For details, see "System Variables", in Chapter 1 of the Developer's Reference.

A node object is created every time a new workstation starts executing a Jade Object Manager client application, as a result of a jomInitialize API call. (For details, see "Initializing a Node", in Chapter 3.)

A process object is created every time an application is started in a Jade Object Manager node, as a result of a jomSignOn API call. (For details, see "Opening a Process", in Chapter 3.) Every process executes in its own operating system thread, and the user is required to create a new thread before signing on again. When the Jade Object Manager application is the jade.exe program, methods available in the Jade language enable you to start new processes from a Jade user process.

No process can access uncommitted changes to a persistent object made by another process running in the same node or a different node. The changes are invisible to other processes until they are committed. Any other process making an unlocked access to an object being updated will receive the most‑recently committed edition, and will not see the uncommitted updates.

Methods can be executed on a client node or a server node. Modifications to persistent objects must be done within persistent transactions. (For more details about server and client execution of methods, see "Method Options", in Chapter 1 of the Developer's Reference.)

The following restrictions apply to persistent objects when using the server or client execution method option.

• 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 also applies to the beginLoad and endLoad and the beginLock and endLock instruction pairs.

• Jade enforces the starting, performing, and finalizing of persistent transactions on a single node (that is, a client or a server node). All of the update operations for the transaction must occur in the same node that started the transaction.

  Jade does not attempt to synchronize the client cache and server cache when accessed by the same process. Server methods should avoid accessing persistent objects that the process is updating on the client node, as changes made to persistent objects in a non-committed transaction are not usually visible to server methods executed during that interval. The same restriction applies to clientExecution methods called from server methods.

  Attempting such an access can cause an exception to be raised (that is, 1276 – Potential cache inconsistency).

All changes that occur when transient objects are created, updated, or deleted during the execution of a server method are sent back to the client node. These changes are then merged with the current transient object population in the client node. The transient object space on both the client and server nodes is then the same as if the method had been executed locally.

As a transaction is effective across client and server nodes for shared transient objects, the beginTransientTransaction instruction makes transaction state active for client methods and server methods, regardless of the execution location. Similarly, the commitTransientTransaction instruction ends transaction state for client methods and server methods.

As is the case for persistent objects, no process can access updated shared transient objects until the commitTransientTransaction instruction is executed. A process attempting such an access without locking will receive the most‑recently committed edition instead.

If the commitTransientTransaction instruction is executed by a server method, the updated objects are sent to the client node before they are removed from the server node cache. This ensures that other processes accessing the objects on the client node will see the latest edition.