mssql-jdbc: Retry when DatabaseName is wrong

Driver version

12.4.0

SQL Server version

Microsoft SQL Server 2022 (RTM-GDR) (KB5021522) - 16.0.1050.5 (X64) Jan 23 2023 17:02:42 Copyright © 2022 Microsoft Corporation Developer Edition (64-bit) on Windows Server 2022 Standard 10.0 <X64> (Build 20348: ) (Hypervisor)

Client Operating System

Windows 10 22H2

JAVA/JVM version

AdoptOpenJDK jdk-8.0.292.10-hotspot

Table schema

(no schema)

Problem description

If you try to connect to SQL Server with the following URL, it will retry for 30 seconds. (invalid_database_name is DatabaseName that does not exist)

jdbc:sqlserver://localhost:1433;DatabaseName=invalid_database_name;responseBuffering=adaptive

Expected behavior

Do not retry if DatabaseName is wrong. (like mssql-jdbc-8.4.1.jre8.jar)

Actual behavior

If DatabaseName is wrong, retry until loginTimeout.

Error message/stack trace

このログインで要求されたデータベース "invalid_database_name" を開けません。ログインに失敗しました。 ClientConnectionId:***
com.microsoft.sqlserver.jdbc.SQLServerException: このログインで要求されたデータベース "invalid_database_name" を開けません。ログインに失敗しました。 ClientConnectionId:***
	at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:262)
	at com.microsoft.sqlserver.jdbc.TDSTokenHandler.onEOF(tdsparser.java:283)
	at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:129)
	at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:37)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.sendLogon(SQLServerConnection.java:5233)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(SQLServerConnection.java:3988)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.access$000(SQLServerConnection.java:85)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection$LogonCommand.doExecute(SQLServerConnection.java:3932)
	at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7375)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:3206)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2713)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:2362)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:2213)
	at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:1276)
	at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:861)
        ......

Any other details that can be helpful

This problem appears to have occurred in #1669. Specifically, I suspect this code deletion is the culprit. https://github.com/microsoft/mssql-jdbc/pull/1669/commits/ac78f50479ab2f33a4f3107d2f1608bf9eaf8fed#diff-5a8fd0ea202eb55761d2a24d0619f2f2bd602ebbfe8e005bf4d112cc7768d840L2722

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 17 (9 by maintainers)

Most upvoted comments

Hi @Takuya-Soda,

I’ve reproduced the issue you are seeing. For a single connection attempt, you will see multiple login attempts, about 1 per second, which gives you the 17 or 31 you were seeing this. This is because for transient errors we continually retry login until loginTimeout is reached (or the error is no longer seen). It’s an interesting thought whether this behavior should be modified, but for now I would recommend the following actions:

  • If you set loginTimeout to a low value (try 1 or 2), then you should see a low number of login attempts. I don’t think its possible to limit it to exactly 1, but you can at least reduce it from 31.
  • We’re currently working on a feature, where, as part of the feature, you can disable retry on current transient errors. This would allow you to set the driver to automatically fail on 4060, without any login retry. This feature is still in development, but we will update this thread with progress, including potential release windows.

Let us know if these steps work for you, and whether you have any further questions.

Retry logic was rewritten in PR 2247, which will be available in driver release 12.5.

We’re currently looking into making changes to retry logic so that connectRetryCount and connectRetryInterval are always respected.