I need to create an object that will represent the state of the table, and I want to be able to use that same object from other QActions, however my object needs to be declared on an element level, meaning each element of that protocol will have it’s own single instance(singleton). I cannot use static as that would mean that all elements running that protocol will share the instance, and their table states may differ. I would like to avoid having to store the state in a dummy parameter within the actual table because that would beat the purpose of storing the state of the table in the object in the first place. Would this even be possible? I’m open to creative solutions as well, even if just as a though experiment.
Hi Edib, this can be achieved by using a static dictionary, with the element ID as key.
I once created the following class to make this more generic and easy to use: https://gist.github.com/TomW-Skyline/805c689e62f0362d845ced2829a91aa1.
Usage:
var instance = ElementInstanceManager.GetInstance(protocol);
var x = instance.MyData;
However do note that the data will remain in memory, even after restarting the element. To make sure that all data gets cleaned up when the element is being stopped (or deleted), it’s important to call RemoveInstance in the IDisposable.Dispose() method of a QAction:
ElementInstanceManager.RemoveInstance(protocol);
Please let me know if more details are required.
Hi,
Could you elaborate a bit more on the reason for needing to have the info in memory?
Is it because the table is changing from different sources? Or too slow to read from within the QAction due to size?
Because having to maintain 2 copies of the same data can present some challenges especially if you start to have to deal with concurrency.
In any case, you could still use a static object as long as you have a way of indexing the data, so something like a static Dictionary where the key is the element ID in the format of <dataminerId>/<elementId> to ensure uniqueness even when dealing with migrated elements.
You would also need to make sure when the element is stopping or gets deleted that you delete the static data entry.
Another alternative would be to have an instanced QAction with a local field/property that would store the value in between executions.
Do note that with this last approach, you would need to have all your entry points in the same QAction
For the key of your dictionary, you probably want to use “dmaId/elementId” in order to avoid any possible issues if an element is migrated from one agent to another. This will be even more likely to be needed when swarming gets into play.
Correct, the key should always be the complete unique identifier of the element as you mentioned.
Updated the answer for clarity.
Hi João,
reasoning behind keeping data in memory is to reduce amount of calls to SLProtocol, I’m working on Polling Manager and I would have to load table in to memory often in order to check if something is ready to be polled. There are other approaches to this problem as well but currently I’m exploring this one. Also since I will be working with the data from the table significantly I would like to reap the benefits of OOP.
I understand that retaining data in memory can improve performance if the data size remains within reason. But I’m not sure why it should be static? QActions can be made dynamic by removing the static keyword from the class and run method definition.
When using a static dictionary, be careful with threading and perhaps use a ConcurrentDictionary.
The only reason I see for it being static is to place it in a precompile QAction in order to be able to access it from different QActions as mentioned in the original question.
Otherwise, I would agree that an instanced QAction would be the way to go since it would give some added protection against memory leaks, which if possible would still be my advice to do.
Still, I do not believe there is an easy way of sharing data between QActions without a static object.
Small note on the IDisposable.Dispose method, is only available from 10.2.9 onwards
See https://docs.dataminer.services/develop/devguide/Connector/LogicQActions.html#implementing-the-idisposable-interface
Prior to that version, an option could be to subscribe to the element state in order to detect when it gets stopped or deleted.