Kill session in SQLServer has executeQuery continue without any Exception on the client

Driver version

8.4.1.jre11

SQL Server version

Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64) \n Nov 2 2020 18:35:09 \n Copyright © 2019 Microsoft Corporation\n Developer Edition (64-bit) on Linux (Ubuntu 18.04.5 LTS) <X64>

Client Operating System

MacOS Mojave (I expect the issue no matter which OS).

JAVA/JVM version

openjdk version “11.0.5” 2019-10-15 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)

Table schema

Not relevant, reproduction case attached.

Problem description

Long running query client (preparedStatement.executeQuery()) is waiting for it’s ResultSet. In SQLServer find the relevant session id, and kill it using: KILL <IDHERE>

1. Expected behaviour: SQLException at the client
2. Actual behaviour: Continues as if nothing was wrong (no results at least)
3. Error message/stack trace: None, not even warnings.

JDBC trace logs

Not really relevant, but when issuing the KILL sessionid -> 2021-01-27 13:25:53.68 spid70 Process ID 55 was killed by hostname <HostName>, host process ID 0.

Reproduction code

Maven reproduction case attached. Please read below for full instructions.

Reproduction case

• Install and setup jdk from https://adoptopenjdk.net, pick one of: 11 LTS + HOTSPOT (or OPENJ9)
• Install and setup maven from https://maven.apache.org
• Docker (makes this easier, or you’ll have to setup the SQLServer version mentioned above manually and change the test code to match your credentials/url):
  • Install and setup docker
  • Install and setup docker-compose
• Extract the .zip
• Open a shell and “cd” into the docker directory
  • docker-compose up -d (see settings.env for details), it sets up the latest docker SQLServer 19 image and binds to port 1433
• Go back to the root directory again and run: mvn clean package This will run the test (see Main.java for details)

What you’ll see is that it prints “Test started…” and then “hangs”, at this point the long running query started.

• Go to SQLServer and execute the following query to find the session of this query:

SELECT r.session_id,
       st.TEXT AS batch_text,
       qp.query_plan AS 'XML Plan',
       r.start_time,
       r.status,
       r.total_elapsed_time
FROM sys.dm_exec_requests AS r
inner join sys.databases d on r.database_id=d.database_id
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS st
     CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) AS qp
WHERE r.database_id = d.database_id
and  d.name='master'
ORDER BY r.cpu_time DESC;

• Then for the correct session id execute: KILL <ID> to kill it.

The maven build will continue as if nothing happened (it will succeed). An SQLException was expected because the user session (and thus the Connection on the client) was killed/aborted.

The current behavior will result in the client application assuming things went fine, while they clearly were not, but the application is unaware of this. This could result in serious problems for applications in general.

To bring down docker and purge the database and it’s volumes, go to the docker directory again and execute: docker-compose down -v

I hope this can be fixed in a future release, if you have any questions please reach out.

Thank you for your time. Martijn

reproduction.zip

[mreuvers]

Hello @rene-ye

Thank you for the quick reply. This test case reproduces all the time (it’s an insane query on purpose here that essentially would never return or after a very very long time).

In any case, the client does react immediately on the kill (it falls out of the executeQuery()) ,but without any Exception. Causing the application to just continue as if nothing was wrong. It’s exactly this behavior that is problematic that it just continues.

Since the client does react to the kill immediately, it should also be able to throw an Exception instead (I am pretty sure if you’d start using the broken connection you’d get Exceptions as well).

[praskutti]

Quick question @pedorro @lilgreenbird : What happens if you SET XACT_ABORT ON before the query?