In a DBMS, a deadlock occurs when two or more transactions are blocked forever, each waiting for a resource that another transaction holds. No transaction can proceed, and the system remains in a standstill until the DBMS breaks the cycle.

Understanding the causes of deadlock is essential to see why this happens and how later techniques like detection, prevention, and avoidance try to stop it.

What Is a Deadlock?

A deadlock in DBMS happens when:

• Transaction $T_1$ holds a resource (for example, a lock on data item X) and waits for another resource Y held by $T_2$.

• Transaction $T_2$ holds Y and waits for X held by $T_1$.

Now both transactions are waiting for each other, and neither can release its resource. This circular dependency is a deadlock.

Simple Example

• $T_1$: Locks X, then tries to lock Y.

• $T_2$: Locks Y, then tries to lock X.

If both reach the second step at the same time, they form a cycle and deadlock.

Main Causes of Deadlock in DBMS

Several interrelated factors cause deadlocks:

1. Resource Contention

Many transactions try to access the same data items (resources) simultaneously.

• Data items are locked (shared or exclusive) for reads and writes.

• If two or more transactions each hold some locks and want others, they may wait for each other, creating cycles.

Resource contention is the basic fuel for deadlocks.

2. Hold and Wait

A transaction can hold one lock and still request others.

• $T_1$ holds a lock on X and asks for a lock on Y.

• $T_2$ holds a lock on Y and asks for a lock on X.

If both requests cannot be granted immediately, the hold‑and‑wait policy allows the circular wait to form.

3. No Preemption

In many DBMS designs, a transaction cannot be forced to release a lock before it finishes.

• Once a transaction holds a lock, only it can release it (on commit or rollback).

• This “no preemption” rule means that if a circular wait forms, it cannot be broken naturally; the DBMS must detect and abort one transaction.

4. Circular Wait

A circular wait occurs when a chain of transactions is formed such that each waits for the next:

• $T_1$ waits for $T_2$

• $T_2$ waits for $T_3$

• $T_3$ waits for $T_1$

This cycle is the top‑level symptom of deadlock. It is usually analyzed using a wait‑for graph, where a cycle in the graph means a deadlock exists.

5. Improper Lock Ordering

If different transactions acquire locks on the same resources in different orders, deadlocks become likely.

• Transaction A: updates Table X first, then Table Y.

• Transaction B: updates Table Y first, then Table X.

Under high concurrency, both may hold one lock and wait for the other, creating a circular wait. Consistent lock ordering (always X then Y, for example) can reduce this risk.

6. Long‑Running Transactions

Transactions that hold locks for a long time increase the chance of deadlock because:

• They tie up resources for an extended period.

• More concurrent transactions may arrive and hit the same resources, forming cycles more easily.

7. High Concurrency

In a multi‑user environment with many transactions, the probability of conflicting lock requests rises.

• More transactions → more chances of inconsistent lock requests → more chances of deadlock.

Databases often see deadlocks clearly under high load.

Why Causes of Deadlock Matter?

• They show that deadlocks are not “random”; they stem from locking policies, resource sharing, and transaction design.

• Knowing the causes helps you understand the later articles on deadlock detection, prevention, and avoidance, which are designed to remove or avoid one or more of these conditions.

Summary

Causes of deadlock in DBMS include resource contention, hold‑and‑wait, no preemption, and circular wait between transactions. Additional factors like improper lock ordering, long‑running transactions, and high concurrency increase the likelihood of deadlock. By understanding these causes, you see why deadlock is a natural side‑effect of concurrency control and why DBMS needs mechanisms to detect, prevent, or avoid it when it occurs.