Blocking is easy to prevent with Microsoft SQL Server.
Microsoft SQL Server is a transaction-oriented relational database management system (RDBMS) that is often used in highly concurrent environments with many simultaneous users. It maintains transactional integrity and database consistency by using locks (for INSERTs) at the table, page, and, in version 6.5, at the row level.
An unavoidable characteristic of any lock-based concurrent system is that under some conditions blocking can occur. Blocking is when one connection holds a lock, and a second connection wants a conflicting lock type on the same data, which forces the second connection to wait, or block, on the first. This article discusses why this happens and provides techniques for understanding, resolving, and preventing blocking problems.
In this discussion, the term "connection" refers to a single logged-in session on the database. Each connection appears as a server process ID (SPID). Each of these are often referred to as a "process," although it's not a separate process context in the normal sense. Rather, each SPID consists of the server-side resources and data structures necessary to service the requests of a single connection from a given client. A single client application can have one or more connections. From the perspective of SQL Server, there's no difference between multiple connections from a single client application on a single client computer, versus multiple connections from multiple client applications on multiple client computers. One connection can block another connection regardless of whether they emanate from the same application or from separate applications on two different client computers.