The first release changes the phase
Locks alone do not specify a correct transaction schedule; acquisition and release need a protocol. Two-phase locking allows acquisition during a growing phase and only releases after entering the shrinking phase.
These phases describe each transaction’s lock behavior, not a global barrier all transactions cross together. Transactions can still interleave, while a lock manager decides whether requests are compatible with existing holders and lock modes.
References: [1]
Constraining schedules does not eliminate waiting
With the required accesses properly protected by the applicable locks, two-phase locking guarantees conflict serializability. It also excludes some serializable schedules, providing sufficient scheduling constraints rather than recognizing every correct possibility.
The basic form can still allow cascading aborts and deadlocks. Strong strict variants retain locks until transaction completion, preventing early dependencies on unfinished changes but also making some schedules more conservative.
References: [1]
Locking and commitment solve different problems
Circular waits still require deadlock detection or prevention, such as finding a cycle in waiting relationships and aborting a victim. The two phases alone do not guarantee progress or supply retry policy after failure.
Two-phase commit instead coordinates commit-or-abort decisions among resource participants. A system can need both concurrency control and commit coordination. Sharing the words two-phase does not make the protocols interchangeable.