Planning to run multiple instances of Sitecore Experience Commerce on one machine?

Sometimes, we as developers, due to time constraints, we maintain the same versions of Sitecore installations on our local machines. I prefer to use one for research and one for client work. I used Sitecore's installation document and set up two instances of Sitecore Experience Commerce, version 9.3.0.

While testing some functionality, I noticed an interesting issue. Let me explain the issue I experienced in detail using a simple example. For discussion's sake, let’s call my two instances A and B respectively.

Before we start, a little background. For the SXA Storefront site to work as expected, we define what templates to be used for each Commerce item (Category, Product, Product Variant, etc.,).

Instance A and Instance B both use the same catalog, Habitat_Master. The concurrency version for Entity-Catalog-Habitat_Master was 25 for instance A and 30 for instance B.

I logged in to Sitecore for instance A where I wanted to update my Template overrides section to use a different set of templates instead of using the ones that are provided out of the box. When I updated them and did a Save. I encountered an exception. The error message was stating that the SQL call to Update Entities failed due to a concurrency error as shown below.

Notice here that even though my instance A connects to Entity Version 25, the save should increment the version number to 26, instead, it is showing 31 (which is instance B’s entity version incremented by 1). So, when I check the value back in the database, the concurrency version still seems to be set at 25 for instance A. I clicked on refresh Commerce cache and it restored the version from the database. This indicates that my save did not persist.

Now, I logged into Sitecore client for instance B and noticed that the Template Overrides section was broken.

I tried to search for those ID’s and did not see any reference. I tried to correct that invalid template ID’s on instance B and I experienced the same concurrency error. This time it was showing me version 26 (which is instance A’s entity version incremented by 1). When I clicked on refresh commerce cache, restored the stable version 30 from the database.

If I log back on to instance A, it is broken over there. So, something seems to be going wrong.

I noticed a couple of things

• The broken item ID references on instance A are for templates from instance B and vice-versa
• Updating templates on instance A is trying to connect to commerce engine connected to instance B and that’s why we end up seeing concurrency errors

As usual, I started troubleshooting with the basics. I did verify all my connections, configurations were correct and after long hours of troubleshooting, I decided to seek help from the Sitecore support team.

I was glad to hear that they were able to reproduce the issue on their side which gave me a sign of hope that it is not just my local environment. After a couple of days, I got a response from the Sitecore team mentioning that the issue was due to one common element between both instances, Redis. A big thank you to the Sitecore team.

Both of my instances were sharing the same Redis instance named with the instance name, “Redis”, which is used by Sitecore to cache commerce items along with the catalog. This ended up in Redis giving out false results ending in concurrency errors.

So, the solution to address this issue is to maintain a unique Redis instance allocated to one instance. If we want to maintain two instances on the same machine, then, we need to define a unique Redis service for each instance.

So, I decided to clean up what was set during installation. Create two Redis instances, one for each instance of SXC 9.3.0.

These are the steps involved in creating a new Redis instance as per the guidance from Sitecore,

• Create an instance with a unique instance name and a preferred qualified port number
• Run the following command under your Redis installation folder, usually located under “C:\Program Files\Redis”
  • redis-server.exe --service-install --service-name <redisInstanceName> --port <portNumber>
• Once the service is installed, run the following command to start the service
  • redis-server.exe --service-start --service-name <redisInstanceName>
• Now, we will update all configuration references under instance A and instance B to use the newly created Redis instances respectively
• First would be to update all Commerce sites (Authoring, Shops, Ops and Minions)
  • Look for “InstanceName” under config.json and replace it with your new Redis instance name
• Next would be to update the Sitecore configuration file located at ~\App_Config\Include\Y.Commerce.Engine\Sitecore.Commerce.Engine.Connect.config
  • Look for <instanceName> and replace it with your new Redis instance name
• Restart IIS

Tested the same use case I mentioned above, and this time I no longer experience concurrency issues. All versions are updating as expected. This is very unlikely to happen in higher environments, but as a best practice, start using unique Redis Instance names to avoid cache related issues.

This is only applicable to instances running on SXC 9.3.0 version. Avoid the hassle I went through by following this small but very important tip on your implementations.

Happy Coding!