by Mike.Sheen » Sat Feb 10, 2018 8:05 pm
We erroneously called it Multi-Thread in Dev-4297 , but what it actually is, is asynchronous. The property in the JiwaCollection class is also called AsynchronousSave - it was renamed from to MultiThreadSave to AsynchronousSave a few years ago.
Multi threading and asynchronous are two different beasts.
It is actually possible the default Asynchronous nature of our collection saves would consume more memory resources - and altering that behaviour with the plugin Scott provided may help - but it will be slower.
In simple terms, when AsynchronousSave is true, collections will issue a SQL INSERT or UPDATE or DELETE asynchronously for each item in the collection. By doing so, you''ll see a performance increase over doing that synchronously, especially when the latency between the application and the SQL Server is higher than a few milliseconds. But it also means there are many more .NET SqlCommands running at one time - and they would all consume memory resources.
As developers we thought shouldn't be concerned about how many asynchronous operations occur concurrently - the .NET Framework and operating system are supposed to manage that for us - so I'm keen to see if the plugin Scott provided addresses this, as it will mean we might have issues in other areas of the software with collections saving with many items.
Ernst - let us know if the plugin Scott provided addresses the issue - we can then look at batching SQL updates asynchronously with an upper limit on the number of asynchronous operations per batch to rein in memory usage, and negate the need for the plugin in future versions.
Mike
Mike Sheen
Chief Software Engineer
Jiwa Financials
If I do answer your question to your satisfaction, please mark it as the post solving the topic so others with the same issue can readily identify the solution