Two-phase locking protocol in a database management system is:

Concept: Two-Phase Locking (2PL) is a concurrency-control protocol used by a DBMS to guarantee serializable execution of concurrent transactions. Every transaction under 2PL has a growing phase, in which it may only acquire locks, followed by a shrinking phase, in which it may only release locks; once a lock is released, no further lock can be acquired.

Application: 2PL governs how concurrent transactions interleave their lock requests, not how the database recovers after a crash and not how log records are written. Guaranteeing serializability is a concurrency-control guarantee only — it says nothing about avoiding a circular wait. Two transactions can each hold a lock the other one needs and wait on each other indefinitely; 2PL has no built-in mechanism (such as a wait-for graph, timeout, or wait-die/wound-wait scheme) to stop this from happening. So 2PL is correctly described as a concurrency mechanism that is not free of deadlock.

Cross-check against the other characterisations:

• A protocol “used for restoring a database after a crash” describes recovery techniques (e.g. write-ahead logging, checkpointing) — a separate concern from lock scheduling during normal execution.

• “Any update to the system log done in 2-phases” describes how log records are written, not how locks are acquired and released; 2PL has no defined relationship to log-write ordering.

• Calling it “not effective in Database” contradicts its core guarantee — 2PL is a foundational, widely used protocol precisely because it does guarantee serializable schedules.