JADE Object Handling

The JADE distributed processing architecture has a single semantic model for all objects and two basic lifetime variations: persistent and transient lifetimes.

Persistent objects, which are permanently stored in the persistent database, live across JADE executions and are shared by all processes in all nodes of the system. The server node enforces concurrency control for persistent objects. Update operations on persistent objects must be performed within transaction state; that is, inside a beginTransaction and commitTransaction pair of instructions.

Changes made to objects within a transaction state are hidden from other processes until committed. This means that other processes accessing these objects will not see the uncommitted updates, but will instead view the most‑recently committed editions.

When the prohibited parameter in the Process class prohibitPersistentUpdates method is set to true, the following operations are prohibited in the current process.

• Executing the beginTransaction and commitTransaction instructions

• Updating, creating or deleting a persistent object

• Cloning or copying to a persistent object

Non-shared transient objects are local to the process that created them; that is, they cannot be accessed by any other process. Because of this, no concurrency control operations are performed when they are updated, which gives optimal performance. These transient objects are automatically removed when the process that created them finishes.

If the transient cache of a node overflows, non-shared transient objects are written out to a .tmp file. Each transient database file is in the following format and is located in the path specified by the TransientDbPath parameter in the [JadeClient] section of the JADE initialization file.

tdb_<host-name>_<pid><designator>.tmp

In this format, the <pid> value is the operating system process identifier and the <designator> value is one of the following.

• [shared], for a node’s shared transient file

• [kbp_nnnnnn], for transient files associated with a kernel background process

• [process-oid], for transient files associated with a user process

If a .tmp file is found to be growing, you can identify the application process to which it belongs by locating the process identifier in the jommsg.log; for example:

2008/02/22 14:23:26.897 000b8-0af4 Jom: Local process sign-on: oid=[187.2], process=0x58f7fe8, no=2, id=2804, type=1 (non-prodn), scm=JadeSchema, app=Jade, 2016.0.0

In this log entry example, [187.2] is the oid for the process object.

The temporary (.tmp) file for each process is deleted when the process terminates. Certain kinds of failure (for example, a node crash) can result in these temporary files not being deleted. You can delete any temporary transient object overflow file that has been left behind, if required.

Shared transient objects are transient objects that are shared by processes in the same node and exist for the lifetime of the node of the process that created them. In addition, concurrency control is locally enforced by the node on which they reside.

Update operations on shared transient objects must be performed within transient transaction state; that is, inside a beginTransientTransaction and commitTransientTransaction pair of instructions.

Shared transient objects and non-shared transient objects reside in the transient cache. In addition, shared transient objects are backed up in a .tmp file with a unique hexadecimal number 1. The shared transient temporary file is deleted when the node terminates.

Shared transient objects were designed to allow you to share objects among the processes of a node at a relatively low cost. Shared transient objects avoid the overhead of performing a persistent transaction. Transient transactions are lightweight transactions that do not involve auditing or communications with the server node.

Updates to shared transient objects are applied when the commitTransientTransaction instruction is executed. As shared transient objects are exclusively locked while being updated, other processes cannot lock these objects until the commitTransientTransaction instruction is executed. Other processes attempting to access these objects without locking will not see the uncommitted updates but instead will view the most-recently committed editions.

No transaction is necessary when creating, deleting, or updating ordinary non-shared transient objects. These objects can be updated at any time.

Transient transactions provide the means to group updates to shared transient objects. All shared transient objects to be updated must be exclusively locked, either manually by the user or automatically by JADE, and they remain locked until the transaction is finished. Other processes trying to get a consistent view of any of those objects by using shared locks or to update them in another transaction will be put into wait state until the completion of the current transient transaction. This guarantees a correct sequence of operations on shared transient or persistent objects, as every JADE process executes independently in its own operating system thread.

An exclusive collection is created when it is updated for the first time. Whenever an exclusive collection is created, regardless of whether it has an inverse reference, the edition of the owner object is updated. An exclusive collection is also created if the instantiate method is called before the collection is updated the first time.