Review brief

Intermediate35 min

A worker service is wrapping its database driver behind one lifecycle-aware class. Calls can begin concurrently during startup, transactions may fail at any step, and shutdown must reject new work while allowing already accepted work to finish.

Behavioral contract

Each Database instance lazily creates at most one Pool, even when the first calls are concurrent; ordinary queries and transactions share it.
A transaction releases its checked-out client exactly once after commit, rollback, or any begin/commit/rollback/work failure.
close() atomically rejects new query and transaction calls, waits for all previously accepted operations to settle, then calls Pool.end exactly once.
Pool creation failure leaves the instance able to retry a later operation, and close before first use completes without creating a pool.

Review instructions

1Trace concurrent first use, each transaction failure point, and calls racing close.
2Anchor each finding to the narrowest useful changed line and explain the resource impact.
3Recommend a direction rather than writing replacement code.
4Prioritize no more than four findings.

Learning objectives

• Create exactly one shared pool under concurrent startup
• Release transaction clients on every outcome
• Coordinate graceful shutdown with accepted work

src/database-driver.tsTypeScript

@@ -0,0 +1,20 @@

1+export interface QueryResult {

2+ rowCount: number;

3+}

5+export interface DatabaseClient {

6+ query(sql: string): Promise<QueryResult>;

7+ release(): void;

8+}

10+export interface DatabasePool {

11+ query(sql: string): Promise<QueryResult>;

12+ connect(): Promise<DatabaseClient>;

13+ end(): Promise<void>;

14+}

15+

16+export interface PoolFactory {

17+ create(): Promise<DatabasePool>;

18+}

19+

20+export type TransactionWork<T> = (client: DatabaseClient) => Promise<T>;

Reference solution

The findings below are ordered by priority.

Findings

1. Ordinary queries create and leak a new pool each time

Location: src/database.ts:12-15

query calls the factory directly instead of using getPool, and the returned pool is never ended or retained. Steady request traffic can create unbounded connection pools while transactions use a different one.

Route every operation through the instance's one shared pool lifecycle.

2. Concurrent first transactions can create multiple pools

Location: src/database.ts:39-44

The field remains undefined while factory.create() is pending. Two first callers can both pass the check, create separate pools, and overwrite one reference, leaking the losing pool.

Memoize the in-flight creation promise, clear it after a creation failure so later use may retry, and publish only one resolved pool.

3. Transaction clients leak on failure paths

Location: src/database.ts:17-30

release() runs only after a successful commit. Work failure and rollback success both skip it, and failures from BEGIN, COMMIT, or ROLLBACK also escape without release. Enough failures will exhaust the pool.

Place exactly-once release in a finally covering every step after checkout, while preserving the relevant transaction error when rollback also fails.

4. Shutdown neither closes admission nor waits for accepted work

Location: src/database.ts:32-36

close simply ends the current pool. A transaction may still own a client, another call can enter concurrently, repeated close calls end the pool repeatedly, and query calls can keep creating entirely new pools afterward.

Introduce an atomic closing state, reject new admission, track and join accepted operations, and memoize one close operation that ends the shared pool only after the tracker drains.

Reasonable non-findings

Lazy creation is allowed and avoids connecting when close occurs before first use.
Explicit BEGIN, COMMIT, and ROLLBACK calls are acceptable with correct cleanup.
Letting the original operation error reject is correct; the lifecycle wrapper need not translate it.