Journal cache

Journal caching is a separately chargeable feature with which you can specify that the system cache journal entries in main storage, before writing them to disk. Journal caching is option 42 of the IBM® i operating system.

After you have purchased journal caching, you can specify it with the JRNCACHE parameter on the Create Journal (CRTJRN) or Change Journal (CHGJRN) commands. The IBM Navigator for i equivalent function is the Cache journal entries option on the Create Journal and Journal Properties dialogs.

Journal caching provides significant performance improvement for batch applications which perform large numbers of changes to the data portion of the journaled objects. The actions that show a performance improvement if journal caching is enabled are as follows:

  • Changes to database files from add, update, or delete operations
  • Changes to data areas from uses of the change data area command or API
  • Changes to data queues from uses of the send data queue API or the receive data queue API
  • Changes to integrated file system objects from various write and fclear operations on journaled stream files

Applications using commitment control will see less improvement (commitment control already performs some journal caching).

Journal caching modifies the behavior of traditional noncached journaling in batch. Without journal caching, a batch job waits for each new journal entry to be written to disk. Journal caching allows most operations to no longer be held up waiting for synchronous disk writes to the journal receiver.

Journal caching is especially useful for situations where journaling is being used to enable replication to a second system.

It is not recommended to use journal caching if it is unacceptable to lose even one recent change in the event of a system failure where the contents of main memory are not preserved. This type of journaling is directed primarily toward batch jobs and may not be suitable for interactive applications where single system recovery is the primary reason for using journaling.

Furthermore, the results from the following commands or API will not display the journal entries in the cache:

  • Display Journal (DSPJRN) command
  • Retrieve Journal Entry (RTVJRNE) command
  • Receive Journal Entry (RCVJRNE) command
  • Retrieve Journal Entries (QjoRetrieveJournalEntries) API

The Display Journal Receiver Attributes (DSPJRNRCVA) Command and the Retrieve Journal Receiver Information (QjoRtvJrnReceiverInformation) API show the total number of journal entries in a journal receiver. However if some of those entries are in the cache, you cannot see these journal entries using the DSPJRN, RTVJRNE, and RCVJRNE commands, and the QjoRetrieveJournalEntries API. For example, if there are 100 journal entries in a journal receiver, the DSPJRNRCVA command and QjoRtvJrnReceiverInformation API show that the total number of entries is 100. However, if the last 25 entries are in the journal cache, you can only view the first 75 entries.

Journal caching also affects remote journaling. Journal entries are not sent to the remote system until they are written from the cache to disk. Since journal entries are not sent to the target system right away, the number of journal entries that are not confirmed are always greater than if you are not using journal caching.

The Change Journal Attributes (CHGJRNA) command can be used to set the maximum time that the system waits before writing journal entries to disk when journal caching is used. Setting the CACHEWAIT time limits the loss of lingering changes when there is a lull in journal entry arrival.

Contact your service representative for more information about ordering journal caching.