Processing of transactions under commitment control - assure_mimix - 10.0

Assure MIMIX Administrator Reference

Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX Administrator Reference
Copyright
2023
First publish date
1999
ft:lastEdition
2024-05-07
ft:lastPublication
2024-05-07T13:36:02.962500

In user journal replication, when commitment control is used on a source system, MIMIX supports two modes of applying transactions under commitment control: immediate apply and delayed apply on the target system. It is important to understand the implications of both modes of commit processing.

In a data group definition, the value specified for the Commit mode element of the Database apply processing (DBAPYPRC) parameter determines how the apply process will handle journal entries that are under commitment control. Supported values are *IMMED and *DLY.

Immediate (*IMMED) - This value is required when multithreaded database apply processing is configured. It is also preferred for configurations that use single-threaded database apply processing when the environment has long running commitment cycles that are eventually committed. With this mode, audits can more accurately compare data while commit cycles are open because fewer transactions are held until the commit cycle closes.

MIMIX immediately applies journal entries that are part of a commit transaction without waiting for the outcome of the commit cycle to be determined. Many users can benefit from using this mode. Most will see improved performance for the database apply process. This can be significant in environments where long-running open commit cycles occur regularly.

In immediate commit mode, uncommitted data can exist on the target system at any point prior to the commit cycle being complete. It is possible that applied entries may be rolled back once all the journal entries in the commit cycle are applied. At any time while entries in the commit cycle are being processed, the target system may contain partial data or extra data that would not be available in delayed mode. This can be a concern if you use data on the target system for more than high availability or disaster recovery, such as for running backups or reports or for supporting cascading environments. If you cannot have uncommitted data on the target node, you should not use Immediate commit mode.

Delayed (*DLY) - This value is only available when single-threaded database apply processing is configured. (Single-threading is in use when the Number of DB apply sessions field (NBRDBAPY parameter) specifies a numeric value.) MIMIX delays applying journal entries that are part of a commit transaction until a C-CM journal entry (set of record changes committed) or C-RB (set of record changes rolled back) for the commit transaction is processed.

When delayed commit mode is used, MIMIX maintains the integrity of the database on the target system by preventing partial transactions from being applied until the whole transaction completes. If the source system becomes unavailable, MIMIX will not have applied incomplete transactions on the target system. In the event of an incomplete (or uncommitted) commitment cycle, the integrity of the database is maintained.

Delayed commit mode is preferred if a large number of commitment cycles will be rolled back. This mode will also prevent reports run on the target system from showing uncommitted data.

However, in environments where long-running open commit cycles occur regularly, the performance of the database apply process can be affected when delayed commit mode is used.

Deadlock condition processing - Regardless of the configured value of commit mode, long-running open commit cycles can result in a deadlock condition for database apply processes. A deadlock condition occurs when database reader (or database send) process cannot place any more entries into a work log for an apply job and the database apply job cannot process the entries in the work log because of an open commit cycle. When MIMIX detects a deadlock condition, it attempts to automatically clear the condition by checking the user journal transactions not yet processed by the database reader (or database send) for the commit or rollback operation and releasing the commit cycle on the target node accordingly so that apply processing can continue. When MIMIX automatically resolves a deadlock, the database apply process issues message LVI0905.

When MIMIX is configured for delayed (*DLY) commit mode, a subset of objects in a commit cycle that MIMIX processed to clear a deadlock may be automatically identified for selection in prioritized auditing. Any objects for which commit rollback entries still exist in the journal after MIMIX cleared a deadlock by performing a commit operation are identified for prioritized auditing.

If MIMIX cannot automatically resolve the deadlock condition, the condition is reported. The value *DLK is displayed in the Open Commit column on view 1 of the Data Group Database Status display and message LVE311D in the message log and the job log of the database reader (or database send) process identifies the job that started the long commit cycle. The condition also triggers email notification for users who have a subscription configured within the Assure UI portal that includes this event. You must take the appropriate action for the application to either commit or rollback the commit cycle. Once the commit cycle has been resolved, MIMIX will be able to automatically clear the deadlock condition.