My application is fully concurrent and async. What about the database?
summary
A .NET console demo opens concurrent connections and shows SQL Server and Azure SQL taking page and key locks, lock escalation at ~5,000 locks, and queries becoming suspended when the app slows; JDBC implicit transactions also hold work open. Azure SQL defaults to read committed snapshot (versioning) while SQL Server historically uses locking; enabling snapshot avoids blocking. Recommended fixes: push logic into stored procedures or use EF Core batching, use memory optimized tables for lock-free MVCC, or apply targeted lock hints.
AI-written summary · about
chapters (17)
- 0:00Introduction to async databases
- 1:23Demo of async connections
- 3:51Understanding locks in databases
- 7:48Transactions and ACID properties
- 12:01Explicit vs implicit transactions
- 17:18Isolation levels explained
- 22:18Locking behavior in queries
- 28:45Page-level locking mechanics
- 31:11Read committed isolation level
- 33:22Repeatable read isolation level
- 36:36Short transactions for concurrency
- 38:45Versioning vs locking
- 42:00Demo of transaction isolation
- 45:14Read committed snapshot isolation
- 48:04In-memory tables for concurrency
- 49:07Batching data for performance
- 51:17Q&A and closing remarks
related talks
50mAchieve peak performance and availability for your SQL Server and Azure SQL workloads with core engi
50mDeveloper Best Practices for Azure SQL : Avoiding common pitfalls when using the Cloud Database
47mMaximizing Database Performance With Isolation Levels- 50mAchieve peak performance and availability for your SQL Server and Azure SQL workloads with core engi
- 47mMaximizing Database Performance With Isolation Levels
- 47mMaximizing Database Performance With Isolation Levels
01h 15mChoose Azure SQL Database and Learn What Every Developer Should Know
53mOptimizing your Azure SQL Database workloads