- 2071 Shrawan · 4+8 marks
Parent-child transactions; locking problems
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).
What are the relationships between parent and child transactions in DS? Write the problems of locking with the solutions to avoid it.
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) |
✓ Answer checked by Claude Opus 5.5 (high effort)
Related questions
- Problems of Lamport's clock; vector clock · Distributed System, chapter 5 · asked 2×
- Locks in transactions; lost update · Distributed System, chapter 8
- Avoiding faults; checkpointing compared · Distributed System, chapter 9
- Geotechnical problems and their solutions · Soil Mechanics, chapter 1 · asked 2×
- Hill climbing and its problems · Artificial Intelligence, chapter 3