How can transaction scope in ASP.NET Core affect SQL Server concurrency?

A transaction should include only database operations that must succeed or fail together. Keeping it open while calling external APIs, waiting for user interaction, performing long computations, or doing unrelated work can hold locks and resources unnecessarily.

In EF Core, SaveChanges normally uses a transaction for the changes in that call when required. Explicit transactions are appropriate for multi-step operations that need a larger atomic boundary.

Production code should keep explicit transactions short, handle exceptions carefully, and avoid mixing long-running non-database work inside the transaction.