MARS Sessions Aren't Closed on Return To Pool

[benrr101]

Describe the bug

I've been working on re-enabling and rewriting some of the tests that were listed as having active issues. The most recent ones were in the MARSSessionPoolingTests. After picking apart the code and figuring out what each one was testing, I was able to boil it down pretty well. However, I noticed that all the tests began failing if I changed the helper method to always use the same connection string instead of passing it in. This led me down a rabbit hole...

These tests are structured to open a connection, open and execute a sequence of commands. There are effectively two kinds of tests:

• Tests that execute then immediately close the results
  • These all use the same connection string
  • Test that only one MARS session is opened, and reused for the lifetime of the test
• Tests that execute but do not close the results
  • These use separate connection strings for each test
  • Test that a new MARS session is opened for each new command that is executed.

For this latter class of tests, if they are reconfigured to use the same connection string as the other tests, all the tests begin to fail. They fail on the assertion that only one MARS session is open. Since the tests all use the same connection string, it means they're pulling from the same connection back out of the pool. This means that even after the connection is returned to the pool, the MARS sessions stay open.

As an aside, the tests previously worked because they would tack one or two spaces onto the end of the connection string, ensuring they would get a new connection pool that hadn't been poisoned by other tests in the series.

To confirm this, I ran a test that only opens one reader, then closes it, closes the connection, reopens it, disposes it, but hits a breakpoint before ending the test. I did a packet capture while running this,: no MARS FIN packets are sent regardless of what happens to the connection, until the test completes (ie, the pool is closed).

According to @David-Engel and @saurabh500 this is not expected behavior!!

To reproduce

Use the attached, rewritten test file. Run all tests and see how they blow up. Run individually and see how they pass. Exclusively running both cases for ExecuteReader_NoCloses will show how the connection is poisoned.

Expected behavior

All tests should pass :) But expected behavior is also that when the connection is closed (ie, returned to the pool) all MARS sessions are closed.

Further technical details

Microsoft.Data.SqlClient v7.0.0-preview1, but likely has been an issue for much longer
.NET 8, 9, and 4.6.2
Windows 11 Enterprise
SQL Server 2022 developer edition, with localhost TCP connection

MARSSessionPoolingTest.cs.txt

[David-Engel]

I have to take back what I said initially about MARS session cleanup. A MARS session is not the same as an open result set. (Obviously, but need to state this to connect the dots as even I was overlapping them in my head.) MARS sessions have to be opened on the server as a client holds open result sets. So leaving MARS sessions open on an existing connection that gets re-used is a perf enhancement. SqlClient can re-use those sessions, as needed. There is no harm in keeping them. There is documentation that talks about this session cache: Enabling Multiple Active Result Sets - ADO.NET Provider for SQL Server | Microsoft Learn