Implementation of singleton pattern in Dyn365FO

In this blog I want to describe two possible implementations of the singleton pattern in Microsoft Dynamics 365 for Finance and Operation. The two implementations differ in the language you implement them and in the scope in which the instance of the singleton class exists. 

Session singleton

If you use “only” X++ to implement the singleton pattern, you will get an instance of the singleton class for each session. To implemented a session singleton using X++ you will use a static variable in combination with an access/get method. 

AOS (IIS/Batch) / AppDomain singleton

If you use X++ in combination with C# to implement the singleton pattern, you will get an instance of the singleton class for each IIS and batch server instance or in other words, you will get an instance of the singleton class for the complete AppDomain. Because the scope of this singleton is a much broader, the implementation is a bit more risky. To lower the risk you should or have to implement a locking mechanism during initialization/invalidation and you also have to design the invalidation wise. To implemented an AOS singleton using X++ in combination with C# you will use a static variable in combination with an access/get method in C#. The singleton is used by calling the C# logic via X++.

Just to get you some context/background on the AOS (IIS/Batch) singleton, we use it e.g. for solving “traveling salesman problem” with an aggregation cube which is an AOS singleton. If it would be possible to have a singleton by environment, we had chosen this.

To get you an idea of how to implement the access/get method in C# including a locking mechanism here is some sample code: 

private static volatile Singleton localSingletonInstance;

private static Object syncRoot = new Object();

public Singleton Singleton

{

get

{

if (_localSingletonInstance == null)

{

// if we don’t yet have an instance, we make sure only one thread instantiates and assigns a new one but we only lock if we actually need an instance

lock (syncRoot)

{

// since it could happen that two or more threads try to lock due to a missing instance, again check if we still need an instance

if (localSingletonInstance == null)

{

_localSingletonInstance = new Singleton();

}

}

}

return _localSingletonInstance;

}        

}

As already mentioned above, an important point for both implementations of the singleton pattern is the invalidation of the singleton. In case you are using the singleton to save/cache heavy aggregations you have to invalidate the singleton instance when the related data get changed. In addition to an automated invalidation, I would always implement a manual invalidation via a button or something similar. 

In which situations are you using the singleton pattern in #Dyn365FO and which implementation are you using? Hopefully you´re not implementing global variable with the singleton pattern, because they are kind of dirty…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s