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
Hi Edib,
Thanks for your question! Here's a detailed explanation of how objects are created and destroyed in the context of SLAutomation scripts:
- 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.
- 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.
- 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.
- 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.
- 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!
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.