Transaction state after client-side CommandTimeout

In SQL Server environments using ADO.NET, SqlCommand.CommandTimeout allows a client to send an attention signal to the server to abort a running batch when a time limit is reached. While this stops the execution of the current statement, the behavior regarding the surrounding transaction remains a point of architectural uncertainty.

When a timeout occurs during a statement that is part of an explicit transaction, the server stops the work, but the transaction itself may remain open and continue to hold locks. This creates a discrepancy between the client-side exception and the server-side session state.

Constraints and Uncertainty

• The SET XACT_ABORT setting influences whether the transaction is automatically rolled back upon certain errors, but its interaction with client-initiated attention signals is not always consistent.
• Rollback duration for large transactions can delay the release of the session, even after the client has received a timeout exception.

Does a client-side timeout automatically trigger a transaction rollback if SET XACT_ABORT is OFF? Under what specific conditions will an explicit transaction remain open and hold locks after a CommandTimeout exception is raised in the application?