JADE Object Caches

On each JADE client node, there is a persistent JADE object cache to hold in-memory copies of persistent objects that have been accessed by JADE sessions, through their associated JADE context, on that node. One of the benefits of caching an object is that the object can be accessed via JADE contexts attached to the client node at a later time without needing to be fetched from the database server node.

Because objects are retained in cache, it is possible to run out of allocated cache space. When this happens, the least‑recently used objects are discarded from cache. If a discarded object is required in the future, the latest edition is fetched from the database.

JADE automatic cache coherency keeps objects in the cache from becoming out of date. When a JADE object is updated, the database server knows which connected caches have copies of the object that are now obsolete. It sends messages to the affected caches, resulting in obsolete objects being discarded. If a discarded object is required in the future, the latest edition is fetched from the database server.

Locking an object guarantees that the copy in cache will be the latest edition.

JADE also maintains a transient JADE object cache on each client node, to contain transient objects created by JADE sessions on that node. Even though cached, the transient objects are visible only to the JADE sessions that created them.

If the transient JADE object cache of a client node overflows, transient objects are written out to a .tmp file. Each transient database file is unique to a specific JADE session and is located in the path specified by the TransientDbPath parameter in the [JadeClient] section of the JADE initialization file.

The file name has the following format.

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

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

[kbp_nnnnnn], for transient files associated with a JADE background session
[session-oid], for transient files associated with a JADE session, where session-oid is the object identifier of the JADE session

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

2014/08/25 15:58:14.399 0b958-bc0c Jom: Local process sign-on: oid=[187.251], process=0x000000000D39DDD0, no=2, id=48140, db=4, type=2, (non-prodn), scm=BankingViewSchema, app=DotNetConnection

In this log entry example, [187.251] is the object identifier of the JADE session. Note that in the message logs, JADE sessions are referred to as local processes.

The temporary (.tmp) file for each session is deleted when the client node 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.

You can set the size of the JADE caches in the JADE initialization file used by the client node.

The default size for the persistent object cache (that is, the default value of the ObjectCacheSizeLimit parameter in the [JadeClient] and [JadeServer] sections of the JADE initialization file) is 80M bytes, and 40M bytes for the transient object cache (that is, the default value of the TransientCacheSizeLimit parameter in the [JadeClient] and [JadeServer] sections of the JADE initialization file).
The minimum size for the persistent and transient object caches is 3M bytes.