In this connection string, our Primary server will be myserver1 with our failover server being myserver2. If the primary server becomes unresponsive, we will fail over to the myserver2. This connection string should work perfectly fine.

In this case, we are either connecting to a named instance (by way of the port), or a default instance on a non-standard port (that being 1433). This may or may not work as expected. If we were able to successfully connect to the Primary Server once, we will cache the failover connection string via the connection to the Primary server. The primary server in that case actually supplies the connection string to the failover partner and we ignore what you put in the actual application connection string. If that happened, we will probably successfully connect to the failoverPartner.

However, if we were not able to connect to the Primary Server at all (i.e. Primary Server is physically down or unreachable), then we will rely on the application connection string to connect to the failoverPartner. Our JDBC Driver doesn't parse the port number for the failoverPartner property. We will treat it as the actual server name. This is what we would see in the JDBC Log output:

Notice that server equals myserver2:1699 with a port of 1433. This is because the port number that was specified in the connection string was not parsed out.

This is the exception you will receive on the application side:

com.microsoft.sqlserver.jdbc.SQLServerException: The TCP/IP connection to the host has failed. java.net.UnknownHostExce ption at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.loginWithFailover(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source)

This issue is currently not going to be changed and will still be present in the 2.0 release of the driver.

Here we have a named instance for the Primary server and just a default instance for the failoverPartner. Lets assume that either the Primary Server is physically down or the SQL Browser service on that server is not running. This will result in the following exception:

com.microsoft.sqlserver.jdbc.SQLServerException: The connection to the named instance has failed. Error: java.net.Socke tTimeoutException: Receive timed out. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.getInstancePort(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source)

In most situations, because we received an exception, we will try and connect again as it should use the failoverPartner at this point. This is what we will see:

com.microsoft.sqlserver.jdbc.SQLServerException: The connection to the named instance has failed. Error: java.net.Socke tTimeoutException: Receive timed out. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.getInstancePort(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source)

Notice the lack of the loginWithFailover method from the callstack. We didn't make it far enough to even attempt the connection to the failoverPartner. In this situation, we are trying to resolve the instance name to a port number. Because we are unable to communicate with the SQL Browser services (UDP 1434) we cannot perform the lookup and we are just erroring out at that point. To work around this issue, you could specify the port number instead of the instance name itself.