---
title: "Parent-child transactions; locking problems"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:parent-child-locking"
source: https://www.bctengineer.com/q/semester_7/distributed_system/parent-child-locking
site: BCT Engineering
---

# Parent-child transactions; locking problems

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: 2071 Shrawan, 4+8 marks
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/parent-child-locking
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

What are the relationships between parent and child transactions in DS? Write the problems of locking with the solutions to avoid it.

## Short answer

Parent starts child sub-transactions; children commit provisionally and inherit locks to parent at commit, can run concurrently with siblings. Locking problems include deadlock (solved by prevention/detection), cascading aborts (strict 2PL), reduced concurrency (finer granularity, shorter transactions), starvation (fair queues), and overhead (hierarchical locks).

## Answer

#### Relationship between parent and child transactions
In a nested transaction, a parent starts child sub-transactions, and the following rules apply:
- A sub-transaction commits only provisionally; its result becomes permanent only when all its ancestors commit up to the top level.
- If a parent aborts, all its sub-transactions abort, even those that provisionally committed.
- A child sees the parent's changes, but the parent does not see the child's until the child commits.
- A child can run concurrently with its siblings, and the parent can start new children, but a parent does not run concurrently with its own children.
- When a child **commits**, its locks are **inherited** by (passed to) the parent; when it aborts, its locks are discarded.
- A child can acquire a lock on an object only if every other transaction holding a conflicting lock on it is one of its ancestors.

#### Problems of locking and solutions
**Problems**
- **Deadlock** can occur when transactions wait for each other in a cycle.
- Lock management has overhead (lock table, acquiring and releasing).
- Locks reduce concurrency; short transactions wait for long ones.
- Locks may be held across a network in distributed systems, and a crashed holder blocks others until timeout.
- Early release (non-strict) can cause cascading aborts.

| Problem | Solution |
|---|---|
| Deadlock | Prevention (lock all at start, ordered locking, wait-die/wound-wait), detection (wait-for graph) with abort of a victim, or timeouts |
| Lost concurrency (long holding) | Use shorter transactions, finer lock granularity, **two-version locking**, or hierarchical locks; lock only what is needed |
| Cascading abort | Strict two-phase locking (hold write locks until commit/abort) |
| Starvation (a transaction never gets a lock) | Fair lock queue (first come first served), timestamps for priority |
| Lock overhead | A granularity hierarchy with intention locks (lock a larger unit when many items are needed) |
| Crashed lock holder | Lock timeouts or lease; lock released when the transaction aborts |
| Distributed locks | Each server manages its own lock; distributed deadlock detection (edge chasing) |

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What happens to sub-transactions that provisionally committed when their parent aborts?
   A. They stay committed
   B. They are also aborted
   C. They become top-level transactions
   D. They are retried automatically
   Answer: B. A sub-transaction's commit is only provisional; its result is permanent only if all ancestors commit. (Key point: Parent abort)

2. What happens to a child's locks when it commits?
   A. They are discarded
   B. They are inherited by its parent
   C. They are passed to its siblings
   D. They are released to everyone
   Answer: B. On commit the parent inherits the child's locks; on abort they are discarded. (Key point: Lock inheritance)

3. Which solution addresses cascading aborts caused by locking?
   A. Lock timeouts
   B. Strict two-phase locking
   C. Wait-for graph
   D. Fair lock queue
   Answer: B. Holding write locks until commit/abort stops others reading uncommitted data, so no cascade. (Key point: Strict locking vs cascading abort)

4. Which is NOT listed as a way to handle deadlock from locking?
   A. Locking all objects at the start
   B. Ordered locking / wait-die
   C. Detection with wait-for graph and victim abort
   D. Allowing dirty reads
   Answer: D. Dirty reads cause cascading aborts and are not a deadlock solution. (Key point: Deadlock handling)

## Related in Distributed System

- [Problems of Lamport's clock; vector clock](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Alamport-problems-vector-clock) — Distributed System, chapter 5, asked 2×
- [Locks in transactions; lost update](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Alock-benefits-lost-update) — Distributed System, chapter 8
- [Avoiding faults; checkpointing compared](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aavoid-faults-checkpointing) — Distributed System, chapter 9

## Related in other subjects

- [Geotechnical problems and their solutions](https://www.bctengineer.com/question.md?key=semester_4%2Fsoil_mechanics%3Ageotechnical-problems-solutions) — Soil Mechanics, chapter 1, asked 2×
- [Hill climbing and its problems](https://www.bctengineer.com/question.md?key=semester_6%2Fartificial_intelligence%3Ahill-climbing-problems-solutions) — Artificial Intelligence, chapter 3