how safe to dynamically switch adapter conn in adapter service

Hello All,

How safe & reliable to switch the adapter connection associated with a adapter service using the built in ART service. -

our requirement is to switch the connection very frequently, inside a repeat step we will switch the connection and call diff DB one after another.

How feasible is it using the built in service? any new idea will be apreciated.


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?

good point, but it will be a problem for clustered env.
if we have single IS, then is it OK to implement this?


Clustering doesn’t enter the picture here.

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.

Instead of using the setAdapterServiceNodeConnection service you should assign the connection name during runtime to the input field $connectionname of the adapter service.

This input has been introduced exactly for this approach.
This will even work when in a clustered environment.
Just make sure that the connections are setup identically on all participating nodes.


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.


Yes, correct. I am not sure, how the connection pooling is being handled while connection names are overriden. Thus asked you to verify.