Question
Accenture
AU
Last activity: 21 Nov 2021 18:04 EST
Does D_pxGetApplicationSettingValue hit the database in each call?
We need to call D_pxGetApplicationSettingValue several times during REST integration calls. This OOTB data page is Thread level so it's not cached to be reused by multiple calls in various requestors.
Does anyone know if a database call is made every time this dpage is referenced? Application Settings are versioned rules so I'm leaning towards no - and I don't think I saw SELECT statements in a Database Trace but I'd like to be sure.
Updated: 21 Nov 2021 18:04 EST
Pegasystems Inc.
AU
Hey @CarloS67, thanks for your question.
From a data page configuration point of view, D_pxGetApplicationSettingValue being Thread-scoped with "Limit to a single data page" turned on means that the data page will reload each time you use it to reference a different system setting than the one previously referenced in the same Thread.
Whether the OOTB function getRuleSystemSetting(...) always makes the trip to the database is inside the private API, so is unlikely to be disclosed in this forum. I would expect the loading of the application setting - a rule, as you mentioned - to be subject to rule resolution, and therefore perform trips to the database in a similar manner to how other rules are loaded. That is, as infrequently as possible.
If you are looking for a different balance of caching application settings for your use case, you could roll your own Requestor- or Node-scoped data page that - for its data source - referenced the same data transform as D_pxGetApplicationSettingValue references. Even if - worst case - the function always makes a trip to the database, this would reduce the number of times the function is called to once per setting per Requestor. This is subject to the usual readonly data page load management, and whatever further load management settings you configure.
Hey @CarloS67, thanks for your question.
From a data page configuration point of view, D_pxGetApplicationSettingValue being Thread-scoped with "Limit to a single data page" turned on means that the data page will reload each time you use it to reference a different system setting than the one previously referenced in the same Thread.
Whether the OOTB function getRuleSystemSetting(...) always makes the trip to the database is inside the private API, so is unlikely to be disclosed in this forum. I would expect the loading of the application setting - a rule, as you mentioned - to be subject to rule resolution, and therefore perform trips to the database in a similar manner to how other rules are loaded. That is, as infrequently as possible.
If you are looking for a different balance of caching application settings for your use case, you could roll your own Requestor- or Node-scoped data page that - for its data source - referenced the same data transform as D_pxGetApplicationSettingValue references. Even if - worst case - the function always makes a trip to the database, this would reduce the number of times the function is called to once per setting per Requestor. This is subject to the usual readonly data page load management, and whatever further load management settings you configure.
Each instance of this data page is a container for one .pySettingValue property. Unless you're referencing thousands of settings or there are a large number of requestors (in which case, consider Node-scoped), this won't have a major memory impact compared to the OOTB data page. Do be mindful of this though.
I hope this helps!