Using Singletons

wolfganguhr

Actually in some calculations we have more than one or two database requests and it is a time and ressource consuming process to handle all request information in every part of the communication and to do all database requests again and again.

This is my proposal which we shall discuss in detail

Therefore I've selected a singleton in this case the last - the "Multithreaded Singleton" and I want do describe what it does and what it does not.

The first point is the singleton connector itself:

public partial class TSingletonConnector
    {
        /// <summary>
        /// Test routine only
        /// </summary>
        /// <param name="AInput">new integer value</param>
        /// <returns>old integer value</returns>
        [RequireModulePermission("FINANCE-1")]
        public static int TTestInfo_1(int AInput)
        {
        	int ih = TTestMonthEnd.Instance.TestObject.ITest;
        	TTestMonthEnd.Instance.TestObject.ITest = AInput;
        	return ih;
        }
    }

This routine only gets the singleton access and runs one method in this case a simple exchange of an integer value.

A rudimentär class itself is:

public class TTestMonthEnd
	{
		private static volatile TTestMonthEnd instance;
		private static object smallTestObject = new SmallTestObject();
		
	private TTestMonthEnd() {}
	
	public static TTestMonthEnd Instance
	{
		get 
		{
			if (instance == null)
			{
				lock (smallTestObject)
				{
					if (instance == null)
						instance = new TTestMonthEnd();
				}
			}
			return instance;
		}
	}
	
	public SmallTestObject TestObject
	{
		get 
		{
			return (SmallTestObject)smallTestObject;
		}
	}
}

public class SmallTestObject
{
	int local = 0;
	public SmallTestObject()
	{
		
	}
	
	public int ITest
	{
		get 
		{ 
			return local;
		}
		set{
			local = value;
		}
	}
}

and then the test works either on the server and in slightly different looking code on the client.

        	Assert.AreEqual(0, TSingletonConnector.TTestInfo_1(3), "First call -> 0");
        	Assert.AreEqual(3, TSingletonConnector.TTestInfo_1(17), "Next call -> 3");
        	Assert.AreEqual(17, TSingletonConnector.TTestInfo_1(17), "Next call -> 17");

So a database record can be read one time and used for the complete rest of user activities.

A small test done from the client looks like:

        private void DoSomething(object btn, EventArgs e)
        {
        	int ih = TRemote.MFinance.GL.WebConnectors.TTestInfo_1(3);
        	MessageBox.Show(ih.ToString());
        	ih = TRemote.MFinance.GL.WebConnectors.TTestInfo_1(12);
        	MessageBox.Show(ih.ToString());
            this.Close();
        }

The first message box value by runnig the fist DoSomething is 0, because that is the initial value inside the singleton. The first value in the second click is 12 because that is the last value.

But two different users do not see each others. The singleton is a private singleton for the user only.

So we need the following

[]A singleton which is common for all users. This is the only way to avoid that two persons want to run a period month end on the same ledger at the same time for example[/:m]
[]A singleton for each main modules - mFinance, mPartner ... This is the only way to avoid a "load data" "do a little bit", "throw away everythig" in period.[/:m][/list:u]

Actually I do not implement a singleton because it is nothing for a one mans single fight. It only makes sense if we want to have it all.

Best regards
Wolfgang

christiankatict

Hi Wolfgang,

the example you bring for the reason for a Singleton Class is for the caching of data.

We should only cache data that is rarely changed, such as lookup values, and that is working well, using the TCacheableTablesManager Class and its methods. That works the same on the server and client side.
Data that is often changed should not be cached because of the need of a mechanism of updating the caches of all Clients at once (which the TCacheableTablesManager takes care of).

If you simply need to access the same data more than once in a single calculation then you can hold it in a local DataTable or DataSet in that Method - but ensure that nobody can change that data outside of that routine, i.e. take out IsolationLevel.Serializable when reading that data in and keep the transaction running as long as you need to access the data in that DataTable/DataSet. Otherwise you could end up using outdated data in memory whenever working with the data you hold in your local DataTables as other users could have updated that very data in the DB in the meantime.

A singleton for each main modules - mFinance, mPartner ... This is the only way to avoid a "load data" "do a little bit", "throw away everythig" in period.

Because of the very real danger of holding outdated data in a Singleton we should not do that because we can't ensure that this will happen - we can't keep a Serializable Transaction open forever!

Regarding the use of Singletons in general:

But two different users do not see each others. The singleton is a private singleton for the user only.

This observation is correct in the context of the PetraServer process. The reason for that is that each user's code runs in its own AppDomain, and Singletons are Singletons only inside their AppDomain. Therefore 'User A' gets his Singleton class instance, and 'User B' gets her own Singleton instance. This is by design, as AppDomains completely shield any data (also static variables and Singleton instances) and more from other AppDomains - which is exactly what we want for security reasons.

A singleton which is common for all users. This is the only way to avoid that two persons want to run a period month end on the same ledger at the same time for example

I see the need for that functionality, but that doesn't necessarily mean we need a Singleton Class. All we need is a central class in the PetraServer's main AppDomain that is under the sole control of the ClientManager Class, which makes sure it is instantiated exactly once.
An instance of that Class would be created at PetraServer startup and this instance would need to be accessible by all Client AppDomains. Conceptually this is the same requirement as with the TCacheableTablesManager Class. A reference to its single, ClientManager controlled instance is passed it into every Client's AppDomain and is accessible in the Client AppDomains via the DomainManager.GCacheableTablesManager variable.
An additional requirement might be that this new Class loads certain data from the DB at instantiation and writes and commits certain data to the DB immediatly after data in the Class changes (e.g. a period month end on a ledger is being started). (This would be done using the PetraServer's own DB connection and transaction, which is independent of each of the Client's DB transactions.) That would mean that such state information would survive the restart of a PetraServer because it is immediately persisted in the DB and that it is available again after a PetraServer restart. While this might not be needed if everything happens in the DB and therefore transactions would be rolled back by the RDBMS in case the PetraServer goes down/is restarted while such processing is running and therefore everything would automatically be back as it was before the start of processing was recorded, this might be a requirement for things that need to be undone before a certain process can be restarted, e.g. files that were created in the file system by such a process need to be deleted (e.g. finance data that archived in text files because it is beyond the retention period when a year end runs).

I am happy to implement such a Class if I am given information on the initial states it needs to control (such as period month end on a ledger is started) and whether they need to be persisted in the DB.

wolfganguhr

Hi Christian

All we need is a central class in the PetraServer's main AppDomain that is under the sole control of the ClientManager Class, which makes sure it is instantiated exactly once.

This is one part we need indeed. And the very interesting question what to fill in this class and what not to fill in. For example if this class holds an Object with all entries of the account table you'll only have to load this table only one time inside a complete server session.

No additional database request, no additional memory ...

On the other side we need an implementation to enable a complex communication between client and server.

The YearEnd is an example for it:

The procedure calculates something and asks for a request. The Question is send to the client and the response is send back to the server.

Ok, I'm reducing this activities as much as I can. But actually I've to switch the complete lights on and off again and again. And this is expensive.

Best regards.
Wolfgang

christiankatict

Hi Wolfgang,

Issue one: Central Object instead of Singleton

This ist one part we need indeed. And the very interesting question what to fill in this class and what not to fill in. For example if this class holds an Object with all entries of the account table you'll only have to load this table only one time inside a complete server session.

I was thinking that this Class would mainly hold some flags or simple data structures, e.g. on which Ledger a Month End/Year End has been started, and not of holding DataTables or other larger data structures in there, although this might be a possibility.
The question is only why such DataTables wouldn't be candidates for Cacheable DataTables, and if that is the case then the problem is already solved differently by using the TCacheableTablesManager - which also allows notifying other Clients of changes to the data, when needed. The a_accounts DB Table you mention is already a Cacheable DataTable and can be retrieved by calling the Method GetAccountListTable of Class Ict.Petra.Server.MFinance.Cacheable.TCacheable!!!
By the way, Cacheable DataTables are loaded only once into server memory and are shared between all Client sessions by the TCacheableTablesManager for the reduction of DB requests and conserving of server memory!

Issue two: Complex communication scenario between client and server

This is tricky, but has been solved in a complex situation: in the Partner Edit screen. I can explain in detail how this works, but that is best done in a phone call and not in the Forum as I would need to walk you through quite a bit of code to explain things.

If you want to implement such a complex communication scenario between client and server using a WebConnector, then yes, you have to 'switch the complete lights on and off again and again', which is expensive.
The solution to that is to use a UIConnector instead of a WebConnector. A UIConnector is stateful on the server side and can hold all the data that was processed so far while these questions are put to the user. Once the response from the user comes back, the server-side logic can simply continue with the data that was held in between the questions. Of course, care needs to be taken that such data which is held between those 'ping-pong requests' can either not get changed by others (by acquiring an Exclusive Lock, which isn't good for DB concurrency), or that data that might have changed in the meantime must be read in again!

Note: UIConnectors are also needed in case a Progress Bar or similar should to be displayed on the Client while the server processes data. The reason for that is that the Client needs to call into an Object on the server side which returns such progress information, and that Object needs to be able to 'ask' the Object that actually processes the data what the progress is, which means that a handle to the stateful Object (=the UIConnector) is needed for that.

Kind regards,

christiankatict

wolfganguhr

Hi Christian

christiankatict wrote
I was thinking that this Class would mainly hold some flags or simple data structures, e.g. on which Ledger a Month End/Year End has been started, and not of holding DataTables or other larger data structures in there, although this might be a possibility.

It is only an idea ...

christiankatict wrote
The question is only why such DataTables wouldn't be candidates for Cacheable DataTables,

Actually they are. I've used them. The only "encapsulation" is to define a clear global variable and to catch and repair all "standard exception" and such things and to define a more understandable interface.

My objects are reading the complete data and holding them in the memory.

GetCurrencyInfo getCurrencyInfo = new GetCurrencyInfo("EUR", "JPY");

This example loads the complete data table into the memory, and sets the primary currency pointer to EUR and the other to JPY and the following test code works properly.

Assert.AreEqual(1.23m, getCurrencyInfo.RoundBaseCurrencyValue(1.23456m), "Round to 2 digits");
Assert.AreEqual(1.0m, getCurrencyInfo.RoundForeignCurrencyValue(1.23456m), "Round to 0 digits");

And without any further database request you can switch to an other foreign currency.

getCurrencyInfo.ForeignCurrencyCode = "GBP";

Be shure, the data behind this are your cacheable datatables.

But the actual question is: How often do you have to load the Currency table? One time per user request, one time per user session or one time per server session?

christiankatict wrote
If you want to implement such a complex communication scenario between client and server using a WebConnector, then yes, you have to 'switch the complete lights on and off again and again', which is expensive.

My real problem is that I do not actuall now what I really need. In the petra the communication is very complex and I'm on the way to join what I can join. But this is a growing process. I've to understand what has to be done first.

My goal is: One request, one answer and then do a DoEverything-Request. But I cannot do it from the scratch. Because petra does not do it in this way.

Assert.AreEqual(1.23m, getCurrencyInfo.RoundBaseCurrencyValue(1.23456m), "Round to 2 digits");
Assert.AreEqual(1.0m, getCurrencyInfo.RoundForeignCurrencyValue(1.23456m), "Round to 0 digits");

christiankatict wrote
The solution to that is to use a UIConnector instead of a WebConnector.

I really need a solution for NUnit because this is the "client" I'm actually developing for. Is there a possibility to use UIConnectors in NUnit?

Best regards
Wolfgang

christiankatict

The questions were resolved in a phone call, which helped greatly in resolving the issues.

thiasg

Dear Christian and Wolfgang,

sorry, that I look into the thread late.

christiankatict wrote
The questions were resolved in a phone call, which helped greatly in resolving the issues.

Till now I did not understand the question and not the answer. Could one of you just summaries both, so that we all learn from this?

Thank you

ThiasG

wolfganguhr

We've discussed this by phone and it is very much easier to do it again.

thiasg

I did not understand, what this is about.

In general be aware, that a singleton in the server would be a single instance per App Domain. In the moment we use one App Domain per connected client. This means, if a user open the many different dialogs, then all dialogs share one instance of the class!
The architecture team is discussing about sessions per dialog in the client. By this there would be a place for storing additional information in the server per dialog.

ThiasG

wolfganguhr

I've made a mistake sorry. I've had a problem and told how to solve it (and solved somthing which was actually not a problem at this time). I've discussed with christan about it and there was an other solution for my problem ...

Sorry but this thread is obsolete too.