Long BRM Running Transactions Due to Improper Use of Transaction Functions/Opcodes (Doc ID 2707012.1)

Last updated on NOVEMBER 13, 2023

Applies to:

Goal

When Billing and Revenue Management (BRM) opcode policy starts a transaction (e.g. fm_utils_trans_open()) then fails to finish the transaction (e.g. via fm_utils_trans_{close,abort,commit}) but returns to the connection managers (CM)'s client with the transaction still open.

This is expected if the CM's client actually executes an opcode expected to leave a transaction open, the most obvious opcode being PCM_OP_TRANS_OPEN, but in the "bad code" cases a problem that arises due to the way BRM opcodes handle a transaction via the fm_utils_trans_*() functions: The next client call to the CM does not know a transaction is open but every attempt to use the pairing of fm_utils_trans_open() + fm_utils_trans_close() simply maintains the current transaction, i.e. while the CM's client *thinks* it is executing multiple opcodes each of which are committing changes to the database the actual fact is that a long-running transaction spanning many potential accounts with no relationship to each other if the client-CM connections are pooled by the client as they often are.

The suggestion is that this type of situation can be triaged much more effectively if the following information is available in such a long-running transaction is made available in the cm.pinlog when the transaction finally errors out minutes or even hours later (due a reaper or other timeout):
- The correlation ID in play when the transaction was opened; and/or
- The first account locked and ideally a count of accounts locked during the transaction before it failed.

Currently, the error message in a pinlog is as follows:

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.