Originally Posted by sajosh
Let me turn the question around on you in a way which might make the situation clearer: how is this app able to limit its number of instances? Obviously, it checks how many ProcessX instances are active, and once some criteria are reached it disallows any more instances of itself to be started.
Notepad, as an example, does not implement any such throttling. You can start as many instances of Notepad as you like, and each one will show up as a separate process. Most apps act this way – they simply don’t care whether other instances are already running. Then there’s the “idempotent” processes like Explorer.exe. It’s almost impossible to start a second instance of Explorer because it has a mechanism for ensuring only one is instance is running at any time…
The way that’s usually done is to implement a “mutex” synchronisation object. Being MUTually EXclusive means a mutex can only be owned by one process at a time (there’s a lot more complexity but it’s irrelevant). When the first instance of ProcessX starts, it creates a named mutex, say “ProcessX_mutex” and it assumes ownership of that mutex. During its own attempted initialisation, a second ProcessX instance will also try to create the same mutex and grab ownership, but that will fail because the mutex is already owned by the first instance. The second instance will simply terminate, silently, without the user ever realizing that it attempted to start. Similar principles can be extended to any arbitrary number of maximum instances, or to any app-specific limitation such as “no more than two processes per database”.
Your app apparently implements this type of protection to prevent more than two processes from concurrently accessing the same DB. It may be a safety thing (locking is only implemented in a two process context), or it may even be licensing (the version which scales to more processors costs more). Either way, you’d have to ask the app vendor exactly how the throttling mechanism is implemented, and whether it is feasible and safe to disable it so you can have more instances working against the same database.
Remember that without adequate synchronisation it is entirely possible for two (or more) threads to mess up a data structure they are both accessing. That can even happen on a single-processor machine because the first thread might get pre-empted half-way through reading a customer record, only to have the second thread come along and alter the entire record before the first thread resumes execution, thereby corrupting the first thread’s view of the data.
Originally Posted by sajosh
To be frank, I suspect that the fact that a second instance (in an admin context) actually works may be a bug in the app. They may be creating a mutex (or other synchronisation object) in a session-specific namespace, and they never intended for the concurrent-access-as-admin to work. In that case, you may be running the risk of logical DB corruption even with just two instances, let alone more.
Asking the app vendor is the best approach here. Good luck with it