The Journal Pool contains copies of journal records that the Source Server must send to the secondary system. To avoid disk I/O in normal operation, this shared repository buffers, in memory, the journal records not yet sent to the communication channel.

The order that transactions insert journal records into the pool determines a global transaction sequence known as a "journal sequence." GT.M does not interleave journal records for different transactions in the Journal Pool; therefore, the journal sequence uniquely determines a global transaction sequence. This global order is recorded in the JNL_SEQNO field of the journal update records. Every GT.M transaction, that updates at least one replicated region, increments the JNL_SEQNO by one.

For performance reasons, GT.M processes write records into the Journal Pool as if it were a circular buffer without concern for buffer overflow. If the Journal Pool overflows, the Source Server detects the condition and automatically obtains the journal records from the journal files and sends them to the secondary system in journal sequence order.

	Note
	Resynchronization is implemented with the same mechanism. At reconnection time, transactions needed for resynchronization are read from the journal files and sent to the secondary in journal sequence order.

The Journal Sequence Number is recorded in the JNL_SEQNO field in the update journal records (specifically of type JRT_SET, JRT_KILL, JRT_FSET, JRT_FKILL, JRT_GSET, JRT_GKILL, JRT_TCOM). This value is set in the journal records, and written into the journal buffer and Journal Pool. The JNL_SEQNO is also copied to the reg_seqno field of the file header of each replicated region updated in the transaction.

All journal update records for a single transaction have the same JNL_SEQNO. Journal update records that belong to different transactions have different JNL_SEQNOs. The JNL_SEQNO reflects the strict sequential order applied to transactions in the database. (Without replication, the normal ordering of transactions is a topological sort order. Replication imposes a strict numeric sort order.) This approach provides a consistent, global transaction order across all replicated regions. The JNL_SEQNO helps synchronize the systems when the systems are not synchronized (i.e., when the secondary system is catching up after a communication failure).

	Note
	Forced removal of the Journal Pool terminates GT.M processes that are attempting to access the journal. Do not delete the Journal Pool unless explicitly instructed by Fidelity