How do I practice coding and algorithm questions?

Use PracHub's coding console to write, test, and debug your solutions in Python or JavaScript. View hints, test against sample inputs, and compare with official solutions.

What difficulty level is this coding question?

This is a medium difficulty Coding & Algorithms question, commonly asked during Onsite rounds at Harvey.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Harvey during technical interviews.

Implement a Database Connection Pool | Harvey Coding Question

Implement a Database Connection Pool

Company: Harvey

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Onsite

Implement a simple database connection pool. You are given a mock database client with a function such as `db.query(connection, sql)` or an equivalent simulated query API. Complete the connection-pool logic so callers can safely acquire and release database connections. Requirements: - The pool has a fixed maximum number of database connections. - `acquire()` returns an available connection if one exists. - If no connection is available but the pool has not reached its maximum size, create a new connection and return it. - If the pool is at capacity and all connections are busy, `acquire()` should wait until a connection is released. - `release(connection)` returns a connection to the pool and wakes one pending waiter, if any. - Prevent invalid releases, double releases, and connection leaks. - The implementation should be safe under concurrent requests. Discuss edge cases such as query failures, timeouts while waiting for a connection, and graceful shutdown of the pool.

Quick Answer: This question evaluates skills in concurrent resource management, synchronization primitives, and robust connection lifecycle handling within database connectivity and systems programming.

Implement the core state logic of a fixed-size database connection pool. To make concurrent behavior deterministic and testable, you are given a sequence of pool operations in the order in which they acquire the pool's internal lock. The pool has at most max_connections physical connections. Connection IDs are assigned as 1, 2, 3, ... when new connections are created. An acquire operation should reuse the oldest idle connection if one exists, otherwise create a new connection if the pool is not at capacity, otherwise place the request in a FIFO wait queue. A release operation must only be accepted from a request that currently owns a connection. If there is a waiting request, the released connection is handed directly to the oldest non-timed-out waiter. Otherwise, it becomes idle. The pool must reject invalid releases, double releases, and duplicate acquire attempts by the same request while it is already holding or waiting. Timeout operations remove pending waiters. Shutdown rejects future acquires, cancels pending waiters, closes idle connections, and allows currently held connections to be released later. Query failures are not represented as a separate operation; in a real pool, callers should release in a finally block after any query failure.

Constraints

1 <= max_connections <= 100000
0 <= len(operations) <= 200000
request_id contains no ':' or ';' characters
The only operation names are 'acquire', 'release', 'timeout', and 'shutdown'
All operations are processed sequentially in the given order, representing a thread-safe serialization of concurrent requests

Examples

Input: (2, [('acquire', 'A'), ('acquire', 'B'), ('release', 'A'), ('acquire', 'C'), ('release', 'B'), ('release', 'C')])

Expected Output: ['acquired:A:1', 'acquired:B:2', 'released:A', 'acquired:C:1', 'released:B', 'released:C']

Explanation: A and B create connections 1 and 2. After A releases connection 1, C reuses that idle connection.

Input: (2, [('acquire', 'A'), ('acquire', 'B'), ('acquire', 'C'), ('acquire', 'D'), ('release', 'B'), ('release', 'A'), ('release', 'C'), ('release', 'D')])

Expected Output: ['acquired:A:1', 'acquired:B:2', 'waiting:C', 'waiting:D', 'released:B;acquired:C:2', 'released:A;acquired:D:1', 'released:C', 'released:D']

Explanation: The pool reaches capacity after A and B. C and D wait in FIFO order. Releasing B wakes C, and releasing A wakes D.

Input: (1, [('release', 'A'), ('acquire', 'A'), ('acquire', 'A'), ('acquire', 'B'), ('release', 'B'), ('release', 'A'), ('release', 'A'), ('release', 'B')])

Expected Output: ['invalid_release:A', 'acquired:A:1', 'invalid_acquire:A', 'waiting:B', 'invalid_release:B', 'released:A;acquired:B:1', 'invalid_release:A', 'released:B']

Explanation: A cannot release before acquiring, cannot acquire twice while holding, and cannot release twice. B cannot release while it is only waiting.

Input: (1, [('acquire', 'A'), ('acquire', 'B'), ('acquire', 'C'), ('timeout', 'B'), ('release', 'A'), ('timeout', 'B'), ('release', 'C')])

Expected Output: ['acquired:A:1', 'waiting:B', 'waiting:C', 'timed_out:B', 'released:A;acquired:C:1', 'invalid_timeout:B', 'released:C']

Explanation: B times out while waiting, so when A releases the connection, the pool skips B and hands the connection to C.

Input: (2, [('acquire', 'A'), ('acquire', 'B'), ('acquire', 'C'), ('shutdown',), ('acquire', 'D'), ('release', 'A'), ('release', 'C'), ('release', 'B'), ('release', 'A')])

Expected Output: ['acquired:A:1', 'acquired:B:2', 'waiting:C', 'shutdown:1', 'rejected:D', 'released:A', 'invalid_release:C', 'released:B', 'invalid_release:A']

Explanation: Shutdown cancels the one pending waiter C and rejects new acquire D. Existing holders A and B can still release, but C no longer owns or waits for a connection.

Input: (3, [])

Expected Output: []

Explanation: With no operations, the pool produces no log entries.

Hints

Track three groups separately: idle connections, current owners, and waiting requests.
A FIFO queue handles waiters, but timeouts may leave stale entries. Consider a set to know which queued requests are still actually waiting.

Quick Overview

This question evaluates skills in concurrent resource management, synchronization primitives, and robust connection lifecycle handling within database connectivity and systems programming.