Synchronous and asynchronous delivery mode for remote journals
The terms asynchronously maintained and synchronously maintained both describe a remote journal function delivery mode for journal entry replication.
If a journal is asynchronously maintained, control is returned to the application generating the journal entry on the source system without waiting for the journal entry to be replicated to the remote journal. An asynchronously maintained remote journal might lag several journal entries behind the total number of journal entries in the journal on the source system. If a journal is synchronously maintained, control is not returned to the application generating the journal entry on the local system until the journal entry is replicated to the remote journal.
Synchronous delivery mode
Synchronous delivery means that the journal entry is replicated to the target system concurrently with the entry being written to the local receiver on the source system. The entry is known on the target system, in main storage, prior to returning control to the user application that deposited the journal entry on the source system. Therefore, the target system knows of all journal entries as they are being made in real-time on the source system. Using this mode allows for recovery without losing journal entries on the target system if the source system fails. Providing journal entries synchronously to a target system will have some affect to the journaling throughput on the local system.
Synchronous delivery mode is only supported when a remote journal is associated with a local journal.
There are certain circumstances, when using synchronous mode, when some journal entries are not immediately sent to the target system. These entries are either not necessary for recovery or the user did not specify that they be forced to disk. Journal entries are sent to the remote journal at the same time that they are forced to disk for the source journal. Since these entries are not forced to disk at deposit time, they are not sent to the remote system.
- Some entries that are not required for data recovery might not be immediately sent to the target system. For example, journal entries for a file close (journal code 'F', entry type 'CL') or a stream file open, (journal code 'B', entry type 'OF').
- User-generated journal entries that use the Send Journal Entry (SNDJRNE) command or the Send Journal Entry API (QJOSJRNE) might not be sent to the target system. If either you, or your application, do not request to force these user-generated entries they will only be replicated to the remote journal when some other action forces them. Therefore, periodically specify FORCE(*YES) when using the send journal entry functions.
- Journal entries that are associated with commitment control transactions might not be immediately sent to the remote system. These entries will be retrievable after the following journal entries have been deposited into the source journal:
- Journal code 'C', journal entry type 'CM' (Commit)
- Journal code 'C', journal entry type 'RB' (Rollback)
- See Remote journal considerations for retrieving journal entries when using commitment control for more information.
When journal caching is being used (JRNCACHE(*YES) on the CHGJRN command), entries that exist only in the cache are not available on the target system. With journal caching, entries are not sent to the target system until they are written from the cache to disk on the source system.
- If the local journal is using journal caching, then journal entries will be bundled up before they are sent to the target.
Asynchronous delivery mode
Replicating a journal entry asynchronously means that the journal entry is replicated to the target system after control is returned to the application depositing the journal entry on the source system. Using this mode allows for recovery that might lose some journal entries if the source system fails. However, this mode has less affect to the journal throughput on the local system in comparison with the synchronous mode.
Journal entry latency might occur when remote journals are asynchronously maintained. Journal entry latency is the difference between the journal entries that exist in the remote journal on the target system from those residing in the journal on the source system. From a recovery standpoint, the source system might be some number of journal entries ahead of what journal entries are known on the target system.
Parent topic:
Planning for remote journalsRelated concepts
Process of adding remote journal Remote journal considerations for retrieving journal entries when using commitment control Confirmed and unconfirmed journal entries