(Commerce Server) How to get the PageGroup[] without instancing a new MarketingContext object

Question

If you take a look at Tom Schultz's Blog, you'll see that he says that if you instance your own Context objects (such as the CommerceContext object), an instance of the SiteConfigReadOnlyFreeThreaded class created in memory as well, and you can't do anything to destroy it. If you do this enough times, you'll eventually get warnings in your Application Log. Here's what the warning looks like:

The Commerce Server runtime has detected that more than # instances of the SiteConfigReadOnlyFreeThreaded object have been created. Creating many SiteConfigReadOnlyFreeThreaded instances will negatively affect the performance of the site. Please refer to the Commerce Server documentation for the recommended use of the SiteConfigReadOnlyFreeThreaded object.

You'll also see that Tom says to use the the Current property of the Context objects to avoid this error, much like this:

ContentSelector cso = CommerceContext.Current.TargetingSystem.SelectionContexts["advertising"].GetSelector();

Doing so re-uses the same singleton instance to avoid re-creating the SiteConfigReadOnlyFreeThreaded object every time you instance a new CommerceContext class.

With me so far? Good :)

Here's what I'm really trying to do: Get a list of all of the Page Groups set up in the Marketing section of Commerce Server. As far as my knowledge goes, here's the only way to do it:

using (MarketingContext ctx = MarketingContext.Create("MyCommerceSite", "MyMarketingAuthorizationStore", AuthorizationMode.NoAuthorization))
{
    PageGroup[] pageGroups = ctx.PageGroups.GetAllPageGroups();
}

As you can see, I'm creating a MarketingContext class, which also creates a SiteConfigReadOnlyFreeThreaded in memory as well, each time it's called (which happens to be frequently).

Is there a way to get the list of all page groups configured without instancing an entirely new MarketingContext object each time I want to do it?

Answer 1

I did some digging, and found the following:

By default, Microsoft sets the threshold for these warnings even cropping up in the error log to 100. It turns out that these warnings are absolutely benign if they are staying under 100 in count consistently.

In my case, I had set the threshold for showing errors to 2, just to show every instance that cropped up, regardless of whether it was a valid concern or not. I've sense upped the limit back to 100, and I haven't seen any adverse affects thus far.