Spike in CustomerInBrmTransactionLock in ECE Cache Post Active-Active Deployment (Doc ID 2795963.1)

Last updated on JUNE 18, 2024

Applies to:

Symptoms

The issue is observed post Elastic Charging Engine (ECE) Active-Active installation. there is spike in CustomerInBrmTransactionLock in ECE cache mostly during bulk call of PCM_OP_CUST_UPDATE CUSTOMER.
During bulk call of CUST_UPDATE_CUSTOMER opcode on the same account/account hierarchy from Siebel, issue is seen and is causing huge load on one billing account, which can have more than 100 or 1000 Service Accounts (SA).
The Billing account and its linked service accounts are not always having same getSiteGroupId.

During one of the call, it is observed CustomerInBrmTransactionLock was not released for more than 6 hours.
Suspect latency in federation causing this issue post Active-Active setup since biillinfo linked to one Account Receivable (AR) are spilt into two getSiteGroupId in ECE cache.

EXPECTED BEHAVIOR
-----------------------
There should not be any spike in CustomerInBrmTransactionLock in ECE cache during bulk call of PCM_OP_CUST_UPDATE CUSTOMER

Steps
-----------------------

The issue can be reproduced at will with the following steps:

1. Pass the opcode for bulk call for Bulk call of PCM_OP_CUST_UPDATE CUSTOMER in ECE Active-Active Setup.

Cause

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