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 laterInformation 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 |