Question to dbConn.executeCachedQuery(SQLStatement) on Mirth Connect Interface Engine

Question

Because of too low set of max limit of processes and sessions in an Oracle DB, sometimes the following error occurs in mirth:

DBConnection - java.sql.SQLException: Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack

due to dbConn.executeCachedQuery(SQLStatement) with the DatabaseConnection Class in Mirth

So these are my questions:

1. Is there any way to throw this response/exception in the channel?
2. Is all data of the SQL query with the exception "lost", if this error occurs or is there an automatic retry?
3. And is there a best practice to handle this (eg to check first the the connection with a getConnection() method)?

Answer 1

I'll answer your questions in order:

1) If you are using the javascript connector, then you should have this in a try catch when you initiate the connection. In the catch, just put the error as Logger.Error(exceptionGoesHere).

If you are using the db connector this should get throw automatically in the logs. To make sure you have logging enabled at the channel level, access the Mirth Connect Server Manager, click on the Server tab and ensure that Channel Log Level is at least set to Error.

2) The way that Mirth Connect works, every time the message is initiated it will hit certain points of the Mirth DB to save the state of the message at that point in time. It's how Mirth guarantees message delivery. With that being said, you can always 'retry' the send manually. Otherwise, if you are using the DB connector there's an option that handles this for you under the Database Reader Settings section. The retry gives you the option to select the number of retries as well as the Retry interval in ms. When I was working there, by default it was set to 3 retries after 10 seconds.

3) Use the default database connector. Everything's already built in for you. Put the extra processing in the transformer to handle anything else. Don't try to re-invent the wheel if everything is already built is the best practice.

If you insist on using a code solution, then make sure all of your code is in a try catch, and make sure your catch is actually logging out the error exception.