October 25, 2017 at 6:58 am
Please help me understand how SSIS loads executable files at runtime. Does it copy the file to RAM at runtime to run it? I'd like to know if many jobs running on th same schedule, running the same executable file, will potentially lock resources to this file. My personal tests haven't been fully consistent and would like to know this before deploying to production.
Thank you in advance.
October 25, 2017 at 7:39 am
reelnoncents - Wednesday, October 25, 2017 6:58 AMPlease help me understand how SSIS loads executable files at runtime. Does it copy the file to RAM at runtime to run it? I'd like to know if many jobs running on th same schedule, running the same executable file, will potentially lock resources to this file. My personal tests haven't been fully consistent and would like to know this before deploying to production.Thank you in advance.
My understanding is that it does not 'load' anything. It just runs the executable. Now imagine five people running the same executable ... depending on the exe, that may or may not be an issue & the same should be true of an Execute Process task.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
October 25, 2017 at 8:40 am
Thank you for your response Phil. It helps in my search. Do you know what the dependent variable may be on the exe? The exe in question is a custom console application I've built to handle universal processes amongst our many clients. This exe can potentially be called at the same time by multiple SQL agent jobs depending on how we implement it. One possibility is having a unique copy of this exe for each client, but that wouldn't be optimal. I'd ideally have one exe copy on our system that each client calls. Do you know the progamming concept I should look out for to avoid the possibilty of locking this single source file? Thanks again, in advance.
October 25, 2017 at 9:06 am
It really depends on what the application is doing. At the basic level all execute process is doing is starting an OS process that runs whatever command you gave it and there's certainly nothing preventing an executable from being loaded and run multiple times in parallel. What is the limiting factor is what exactly the process is doing, for example is it using some shared resource like writing to a shared log file that will crash if multiple instances try to use it? Is it parameterized so each client can call it with appropriate inputs for what they're doing without conflicts?
October 25, 2017 at 9:14 am
reelnoncents - Wednesday, October 25, 2017 8:40 AMThank you for your response Phil. It helps in my search. Do you know what the dependent variable may be on the exe? The exe in question is a custom console application I've built to handle universal processes amongst our many clients. This exe can potentially be called at the same time by multiple SQL agent jobs depending on how we implement it. One possibility is having a unique copy of this exe for each client, but that wouldn't be optimal. I'd ideally have one exe copy on our system that each client calls. Do you know the progamming concept I should look out for to avoid the possibilty of locking this single source file? Thanks again, in advance.
I'm no expert in this, but my expectation is that while EXEs do get locked at file level during execution, that does not mean that they cannot be called (and executed) from process 2 while already executing process 1.
I suggest that you set up a few Agent jobs and test it ... should not take too long. Add in a delay (in the EXE), if necessary, to make sure there is an overlap in the calls.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
October 25, 2017 at 6:40 pm
ZZartin - Wednesday, October 25, 2017 9:06 AMIt really depends on what the application is doing. At the basic level all execute process is doing is starting an OS process that runs whatever command you gave it and there's certainly nothing preventing an executable from being loaded and run multiple times in parallel. What is the limiting factor is what exactly the process is doing, for example is it using some shared resource like writing to a shared log file that will crash if multiple instances try to use it? Is it parameterized so each client can call it with appropriate inputs for what they're doing without conflicts?
This is exactly what I needed. I ultimately found a couple other sources that stated the same, including a peer. It is parameterized, and they all will run within their own client environments so I believe I should technically be OK. Many thanks for your response ZZartin.
October 25, 2017 at 6:49 pm
reelnoncents - Wednesday, October 25, 2017 8:40 AMThank you for your response Phil. It helps in my search. Do you know what the dependent variable may be on the exe? The exe in question is a custom console application I've built to handle universal processes amongst our many clients. This exe can potentially be called at the same time by multiple SQL agent jobs depending on how we implement it. One possibility is having a unique copy of this exe for each client, but that wouldn't be optimal. I'd ideally have one exe copy on our system that each client calls. Do you know the progamming concept I should look out for to avoid the possibilty of locking this single source file? Thanks again, in advance.
I'm no expert in this, but my expectation is that while EXEs do get locked at file level during execution, that does not mean that they cannot be called (and executed) from process 2 while already executing process 1.
I suggest that you set up a few Agent jobs and test it ... should not take too long. Add in a delay (in the EXE), if necessary, to make sure there is an overlap in the calls.
[/quote
Thank you for your advice, Phil. Always astonished at how you're typically the first person to respond to any of my posts. Model worker, you 🙂 Have a good one!
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply