I have a Kentico 13 .NET Core website which uses the IUserInfoProvider dependency, injected via constructor, on a number of Widgets.
We are seeing strange behaviour whereby:
- one Widget uses
_userInfoProvider.Set() to persist some changes to a user,
- the same Widget then uses
_userInfoProvider.GetAsync() to confirm the changes are saved,
- the user then moves to a different page whereby a different Widget uses
_userInfoProvider.Get() to read the same user,
- the user which is retrieved does not show the changes persisted.
We are having trouble understanding why that second call, made within a different page request and from a different Widget, would not see changes which the first Widget has confirmed are persisted.
I wondered if this could be related to the scoping of the injected IUserInfoProvider and/or caching being implemented within Kentico.
Has anyone witnessed similar behaviour?
Update: 15 November 2023
It has been suggested that this could be related to the system running within a load balanced environment where one server is persisting the updates while the other is failing to read the newly persisted data.
As I am unable to replicate the problem locally (single website) but do see the issue intermittently on our Staging environment (load balanced 2x CD servers), this may be a route worth investigating.
I can see from looking at the CMS source code that the IUserInfoProvider can be configured to cache data.
In order to enable caching, it looks as though AppSettings needs to be configured to include CMSUseHashtable... entries, which I can't locate.
Has anyone witnessed similar behaviour across a load balanced environment?