Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Master Profile cache

Updated on February 16, 2021

The topics in this section describe the Master Profile access mechanism and configuring the Master Profile cache.

Accessing the Master Profile

The 8.2 version of the application introduces some changes to the way that the master profile is loaded and saved so that the overall performance of the application improves. No changes are required to use the new mechanism, unless some kind of customization has been done in that part of the application. A proper impact assessment is required in that case.

The new model keeps the interface with the rest of the application unaltered. Customers are still expected to retrieve the Master Profile using GetMasterProfile (data retrieval plus synchronization) and D_GetMasterProfile (data retrieval). The persistence of the data is still expected through SaveWorkFolder.

The main changes are implemented at the time of loading D_GetMasterProfile, a thread level data page loaded in every interaction. The changes ensure that the master profile is only loaded from the database when data has changed. Otherwise, it reuses information already in memory.

To support this new mechanism, two new data-pages have been created:

(Requestor) – Data page to store the last version of the master profile that was loaded or saved for a given customer.
(Interaction) – Data page that returns the last time the master profile was persisted into the database (the last time that changes were made).

In order to make the most of this mechanism and to automatically adopt it in future related features, it is important that customers let the application manage the master profile or, if absolutely required, access it using the existing interface as defined above (GetMasterProfile/SaveWorkFolder).

Configuring the Master Profile cache

To enable customers to find the right balance between memory footprint and performance in their applications, the Master Profile access mechanism support two different working modes:

No cache
Under this working mode, D_GetMasterProfile bypasses the cache and retrieve the data directly from the database. This working mode benefits customers with powerful database infrastructure and with complex Master Profiles such that a in-memory copy of the Master Profile from the cache takes longer than an access to the database.
Under this mode, D_GetMasterProfile checks first the cache and, if the customer Master Profile requested is available, it retrieves it from there. This working mode benefits customers with simple Master Profiles, where an in-memory copy is more efficient than a retrieval from database. The application uses this configuration by default.

To keep the growth of the cache under control, the application maintains a limit in the number of Master Profiles that can be maintained in the cache. By default, the application is configured to managed no more than ten Master Profiles, but this is a threshold that can be changed through configuration.

Dynamic system settingsValue


Flag to activate the access to the Master Profile through cache. When the value is set to true, the system makes use of the cache. A value of false will bypass the cache.


Number of active instances in the Master Profile for the requestor. When no value is set, the system uses a value of 10.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us