Life cycle of objects in scripts

Solved123 views#automationscript Automation object life cycle
1
0 Comments

Hello Dojo,

I know that when we use static objects in connectors they are shared between all elements running that connector, and if we use non-static objects, each element gets it's own instance of the object that lives until element is stopped/restarted.

I'm wondering about this life cycle of objects in automation scripts context.

  • When are objects created and destroyed in automation script? If I run same script 10 times, with static properties, do I have to initialise them each time?
  • If I do have to initialise them each time, is there a way to share objects across multiple runs of the same script?
  • Is there a difference between static and non-static objects in AS context, from DataMiner perspective(not including differences that come from .NET itself)?
  • Is there a difference between scripts defined as libraries and those that aren't?

Thank you,
Cheers

Thomas Ghysbrecht [SLC] [DevOps Enabler] Answered question 5 days ago

2 Answers

3
11.96K 0 Comments

Hi Edib,

Automation scripts are run as part of the SLAutomation process. As such, the life cycle of objects in a script respects the life cycle of C# objects in a project, where you can see each script almost as a class in that process.

To answer your specific points:

  • Static objects are created in the first script execution and will live while SLAutomation runs and the script has not been edited. Normally this process only stops when DataMiner stops but since it is not a critical process it may crash and start back up without DataMiner restarting at which point objects will need to be initialized again.
    So if you run the same script on the same DataMiner agent 10 times, the static objects will only be initialized once.
    If you modify the script then it will reinitialize all static objects.
  • They are only initialized once and the static object should remain in memory across multiple executions on the same DataMiner agent, keep in mind that a script may execute on a different agent where the object will not necessarily have the same content in memory.
    If you just need basic memory persistence then a static object should be enough but if you want 100% guaranteed "survival" and synchronization of data then you should not rely on static objects and you should use a saved parameter on an element or something similar
  • Same as regular C# and .NET, DataMiner just executes the code with access to the helper objects like the Engine class | DataMiner Docs
  • Not too familiar with the libraries part but I would say it follows the same rules.
Edib Šupić [SLC] [DevOps Catalyst] Selected answer as best 5 days ago
4
4.63K 1 Comment

Hi Edib,

Thanks for your question! Here's a detailed explanation of how objects are created and destroyed in the context of SLAutomation scripts:

  1. Lifecycle of Automation Script Objects:
    • In SLAutomation, each Automation script is compiled into a unique DLL and loaded into the .NET runtime.
    • When you run a script, the method is executed on a 'Script' class specific to that version of the script. If you change even one character in the script, a new DLL is generated, and .NET treats it as a completely new class.
  2. Behavior of Static Properties:
    • Static properties in your script (or any class used within it) are shared across multiple runs of the same script version. This means you can re-use static values across runs without reinitializing them.
    • However, DataMiner does not add any custom logic to manage these static properties. Their lifecycle is controlled by the .NET runtime, and you need to handle potential memory leaks or resource management issues.
  3. Updating the Script:
    • When you update an Automation script, a new DLL is created, and the previous script's statics are no longer accessible. This effectively resets any shared data stored in static properties.
  4. Script Libraries:
    • Script libraries follow the same principle: they are compiled into unique DLLs for each version. If you modify the library script, all static references will be lost, as a new DLL is generated.
  5. SLAutomation Process Restart:
    • Keep in mind that static values are stored in memory as long as the SLAutomation process is running. If SLAutomation restarts, all static data will be lost.

To answer your specific questions directly:

  • Do you need to initialize static properties each time? No, static properties persist across script runs for the same script version. However, if the SLAutomation process restarts or you update the script, the statics will need to be reinitialized.
  • Can you share objects across multiple runs of the same script? Yes, you can use static properties to share data across runs of the same script version. Just be cautious about resource management and memory leaks.
  • Difference between static and non-static objects in Automation scripts: Static objects persist across runs of the same script version, while non-static objects are instantiated fresh for each script run and are destroyed when the script finishes execution.
  • Difference between libraries and non-library scripts: Libraries behave the same as regular scripts when it comes to static properties. Each version of a library script is compiled into its own unique DLL, so updating a library script results in loss of static data.

Let me know if this clears things up or if you have further questions!

Thomas Ghysbrecht [SLC] [DevOps Enabler] Posted new comment 5 days ago
Thomas Ghysbrecht [SLC] [DevOps Enabler] commented

Seems like João was quicker than me. I guess that my reply also can confirm that the script libraries work pretty much the same as the scripts.