Fixed an issue where getting permissions from DB would fail at times

[valadas]

While working on #6952 this would fail after each restart for some reason, with this change it no longer does. I don't know if this is a good fix performance-wise, any ideas @bdukes ?

Summary

[thienvc]

1. private static readonly DataProvider Provider = DataProvider.Instance();
2. private static DataProvider Provider => DataProvider.Instance();

I believe the first approach is better for performance. Given that Provider is a high-traffic object in our codebase, using static readonly ensures we only resolve the dependency once, whereas the current => syntax triggers a factory lookup on every single call.

[valadas]

Yes but Provider is null at times. So far I can reproduce this way:

• Run a full build and install DNN from the produced install artifact
• Build the library in debug mode. This will trigger a site restart and then Provider is null and we get these errors on page for each an every module:

[valadas]

I pushed an additional commit that makes it better, however I am scared that this hides an underlying issue with DI or the ComponentModel pattern thing. So I put this in draft. It looks like I also cannot place a module on a page, $.dnnSf is not on the page and I'll investigate that too which may show an issue affecting both maybe...

[thienvc]

private static DataProvider _provider;
private static DataProvider Provider => _provider ??= DataProvider.Instance();

I'm curious if doing it this way would be more feasible.

[donker]

IMHO I think the way now proposed is fine with the call inside the callback. The DataProvider.Instance() is only called when the cache expires. I'd prefer not to put anything at class level as down the line someone may inadvertently use it which is not desirable. It's only there for the callback.

[mitchelsellers]

This change has me slightly confused.

Why are we keeping a dataProvider private that is readony only, and introducing a new static, but changing some implementations to use dataProvider and others to use Provider?

I would expect all to the be the same. The static nature of that provider I guess also scares me, but maybe that is the proper intention context.