Transactions in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a NestJS service method uses a transaction but an error occurs?

Consider a NestJS service method that wraps multiple database operations inside a transaction using TypeORM's queryRunner. If one operation fails and throws an error, what is the expected behavior of the transaction?

NestJS

async function performOperations(queryRunner) {
  await queryRunner.startTransaction();
  try {
    await queryRunner.manager.save(entity1);
    await queryRunner.manager.save(entity2);
    throw new Error('Failure');
    await queryRunner.commitTransaction();
  } catch (error) {
    await queryRunner.rollbackTransaction();
    throw error;
  } finally {
    await queryRunner.release();
  }
}

A Only entity1 is saved; entity2 is not saved due to the error.

B Neither entity1 nor entity2 is saved; the transaction rolls back all changes.

C Both entity1 and entity2 are saved permanently despite the error.

D The transaction commits partially, saving entity1 and rolling back entity2.

💡 Hint

Think about what a transaction does when an error occurs inside it.

When an error occurs inside a transaction, the rollbackTransaction() method undoes all changes made during the transaction. This means none of the entities are saved.

📝 Syntax

intermediate

Which option correctly starts and commits a transaction using TypeORM's QueryRunner in NestJS?

Choose the code snippet that correctly starts a transaction, performs an operation, and commits it using QueryRunner.

A await queryRunner.startTransaction(); await queryRunner.manager.save(entity); await queryRunner.commitTransaction(); await queryRunner.release();

B await queryRunner.manager.startTransaction(); await queryRunner.save(entity); await queryRunner.commit(); await queryRunner.release();

C queryRunner.startTransaction(); queryRunner.manager.save(entity); queryRunner.commitTransaction(); queryRunner.release();

D await queryRunner.begin(); await queryRunner.manager.save(entity); await queryRunner.commit(); await queryRunner.release();

💡 Hint

Check the exact method names on QueryRunner for starting and committing transactions.

The correct methods are startTransaction() to begin and commitTransaction() to commit. All are async and should be awaited.

🔧 Debug

advanced

Why does this NestJS transaction code cause a 'QueryRunner already released' error?

Review the following code snippet. It throws a 'QueryRunner already released' error when running multiple transactions sequentially. What is the cause?

NestJS

async function runTransaction(data) {
  const queryRunner = dataSource.createQueryRunner();
  await queryRunner.connect();
  await queryRunner.startTransaction();
  try {
    await queryRunner.manager.save(data);
    await queryRunner.commitTransaction();
  } catch (err) {
    await queryRunner.rollbackTransaction();
  } finally {
    await queryRunner.release();
  }
}

await runTransaction(entity1);
await runTransaction(entity2);

A The queryRunner is released inside the function, so calling runTransaction twice creates conflicts.

B The queryRunner is not connected before starting the transaction, causing the error.

C The dataSource is not initialized, so queryRunner cannot be created.

D The function does not await commitTransaction, so the release happens too early.

💡 Hint

Consider what happens to the queryRunner after release() is called.

Each call creates a new queryRunner and releases it properly. The error occurs if the same queryRunner instance is reused after release. Here, the code is correct if each call uses a fresh queryRunner. The error usually means queryRunner is reused after release.

❓ state_output

advanced

What is the final state of the database after nested transactions with savepoints in NestJS?

Given the following pseudo-code using TypeORM's QueryRunner with savepoints, what data remains saved after execution?

NestJS

await queryRunner.startTransaction();
try {
  await queryRunner.manager.save(entityA);
  await queryRunner.query('SAVEPOINT sp1');
  await queryRunner.manager.save(entityB);
  throw new Error('Error after sp1');
  await queryRunner.query('RELEASE SAVEPOINT sp1');
  await queryRunner.commitTransaction();
} catch (e) {
  await queryRunner.query('ROLLBACK TO SAVEPOINT sp1');
  await queryRunner.commitTransaction();
}

A Both entityA and entityB are saved permanently.

B Only entityB is saved; entityA is rolled back.

C Neither entityA nor entityB is saved; the entire transaction is rolled back.

D Only entityA is saved; entityB is rolled back to the savepoint.

💡 Hint

Think about what rolling back to a savepoint does inside a transaction.

Rolling back to a savepoint undoes changes after that savepoint but keeps earlier changes. So entityA is saved, entityB is rolled back.

🧠 Conceptual

expert

Why should you avoid long-running transactions in NestJS applications?

In NestJS applications using database transactions, why is it important to keep transactions short and avoid long-running ones?

A Long transactions are automatically converted to read-only, preventing data changes.

B Long transactions automatically commit after a timeout, risking partial data saves.

C Long transactions can lock database rows or tables, reducing concurrency and causing performance issues.

D Long transactions consume less memory but increase CPU usage drastically.

💡 Hint

Consider how databases handle locks during transactions.

Long-running transactions hold locks longer, blocking other operations and hurting performance and scalability.