I’d offer that it is not safe at all. That service is intended for “off-line” usage, not for switching the connection at run-time in prod. The risk is that in the multi-threaded environment of IS, one thread switches it, then another thread gets control and switches again, then the original thread gets control back and then proceeds to interact with the wrong DB. Classic race condition that can give unpredictable results.
The only way I can think of to make it safe would be to modify all the services that invoke the JDBC services so that they somehow serialize their calls–only one thread using any of the affected adapter services at a time. Doable, but maybe not scalable and maybe not worth the trouble?
IMO, it is not okay to change the connection on the fly at run-time. The multi-threaded environment of IS, where multiple threads servicing multiple requests are executing, will produce unpredictable results.
While passing $connectionName, see how the ‘connection pool’ behaves. For ‘n’ requests, does it use ‘n’ connections or ‘2n’ connections as connection name is passed dynamically. If you have high flow of data into your system, do this test so that you don’t have problems in production when you have huge volume.
Yes this is the exact solution for pointing different DB at run time.
But I can’t get why there is chances for 2n connection for n request.
Suppose I have 2 connection(connection1 and connection2) and have created adapter service using connection1 and at run time we are pointing connection2 by passing $connectionName.
Then so far I know connection pool will only get from connection2 and not from connection1.
Is this the scenerio for which you are asking there may be 2n connection Or is there any other scenario for which there may be 2n connection.