My Oracle Support Banner

Clarification on cm_cache Management Edge Case (Doc ID 3079892.1)

Last updated on APRIL 02, 2025

Applies to:

Oracle Communications Billing and Revenue Management - Version 15.0.0.0.0 and later
Information in this document applies to any platform.

Goal

The cm_cache_update_entry function primarily performs two operations:

Clearing the memory allocated for the old flist.
Allocating new memory for the updated flist.

If the cm_cache_find_entry function is called between these two steps, how is this scenario handled?

For example, consider a system with two custom opcodes:

custom_opcode1 retrieves a reference to a flist from the cache and uses its data for logical processing within the same opcode.
custom_opcode2 updates the cache with the latest flist as needed.

The cm_cache_find_entry function is described in the cm_cache header file as follows:

/*
* Call to find an entry.
* Returns a pointer to the flist (read-only), or NULL if not found or in case of an error.
* *errp is set to PIN_ERR_NONE if found, otherwise PIN_ERR_xxx.
*/

Since the returned flist is explicitly mentioned as "read-only," it suggests that it is a reference to the cache memory rather than a copy.

However, even if it is a copy rather than a reference, when cm_cache_find_entry and cm_cache_update_entry operate on the same cache simultaneously, could there be a scenario where cm_cache_find_entry returns NULL or an error? Given that cm_cache_update_entry is a two-step process, after step 1, the entry would no longer be available in the cache, potentially causing cm_cache_find_entry to fail.

How this situation is internally managed?
 

Solution

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Goal
Solution


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