The 8.2 version of the application introduces some changes how 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.
Accessing the Master Profile
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 when 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.
The following two data pages support this new mechanism:
- (Requestor) – Data page to store the last version of the master profile 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).
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 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 retrieves the data directly from the database. This working mode benefits customers with powerful database infrastructure and with complex Master Profiles such that an in-memory copy of the Master Profile from the cache takes longer than 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 retrieval from a 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 manage no more than ten Master Profiles, but this is a threshold that can be changed through configuration.
|Dynamic system settings||Value|
|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 bypasses 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.|