Transactions in NestJS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start a transaction using TypeORM's QueryRunner.

NestJS

const queryRunner = dataSource.createQueryRunner();
await queryRunner.connect();
await queryRunner.[1]();

Drag options to blanks, or click blank then click option'

AstartTransaction

BcommitTransaction

CrollbackTransaction

Drelease

Attempts:

3 left

💡 Hint

Common Mistakes

Using commitTransaction instead of startTransaction

Calling release before starting the transaction

To begin a transaction, you use startTransaction() on the QueryRunner.

2fill in blank

medium

Complete the code to commit the transaction after successful operations.

NestJS

try {
  // some database operations
  await queryRunner.[1]();
} catch (error) {
  await queryRunner.rollbackTransaction();
}

Drag options to blanks, or click blank then click option'

AstartTransaction

BcommitTransaction

Crelease

Dconnect

Attempts:

3 left

💡 Hint

Common Mistakes

Calling startTransaction again instead of commitTransaction

Forgetting to commit and only rolling back

After successful operations, you commit the transaction using commitTransaction().

3fill in blank

hard

Fix the error in the transaction cleanup by completing the code to release the QueryRunner.

NestJS

finally {
  await queryRunner.[1]();
}

Drag options to blanks, or click blank then click option'

Arelease

BrollbackTransaction

CcommitTransaction

DstartTransaction

Attempts:

3 left

💡 Hint

Common Mistakes

Calling commitTransaction or rollbackTransaction in finally block

Not releasing the QueryRunner causing connection leaks

After finishing the transaction, always release the QueryRunner with release() to free resources.

4fill in blank

hard

Fill both blanks to create a transaction that rolls back on error and releases the QueryRunner.

NestJS

try {
  await queryRunner.startTransaction();
  // operations
  await queryRunner.commitTransaction();
} catch (error) {
  await queryRunner.[1]();
} finally {
  await queryRunner.[2]();
}

Drag options to blanks, or click blank then click option'

ArollbackTransaction

Brelease

CstartTransaction

DcommitTransaction

Attempts:

3 left

💡 Hint

Common Mistakes

Swapping rollback and release methods

Forgetting to release the QueryRunner

On error, rollback the transaction with rollbackTransaction(), then always release the QueryRunner with release().

5fill in blank

hard

Fill all three blanks to create an object that maps entity names to their repository instances inside a transaction.

NestJS

const repositories = {
  [1]: queryRunner.manager.getRepository([2]),
  [3]: queryRunner.manager.getRepository(ProductEntity),
};

Drag options to blanks, or click blank then click option'

A"userEntity"

BUserEntity

C"productEntity"

DProductEntity

Attempts:

3 left

💡 Hint

Common Mistakes

Using unquoted keys or quoted class names

Mixing keys and values incorrectly

Keys are strings like "userEntity" and "productEntity", values are entity classes like UserEntity and ProductEntity.

Practice

1. What is the main purpose of using transactions in a NestJS application with a database?

easy

A. To automatically generate database schemas

B. To ensure multiple database operations succeed or fail together

C. To speed up database queries by caching results

D. To log all database queries for debugging

Solution

1. Step 1: Understand what transactions do

   Transactions group multiple database actions so they either all succeed or all fail, preventing partial updates.

2. Step 2: Identify the purpose in NestJS context

   In NestJS, transactions keep data consistent by ensuring grouped operations are atomic.

3. Final Answer:

   To ensure multiple database operations succeed or fail together -> Option B

4. Quick Check:

   Transactions = atomic operations [OK]

Hint: Transactions keep grouped DB actions all-or-nothing [OK]

Common Mistakes:

• Thinking transactions speed up queries
• Confusing transactions with schema generation
• Assuming transactions are for logging only

2. Which of the following is the correct way to start a transaction using TypeORM's DataSource in NestJS?

easy

A. dataSource.transaction(async (manager) => { /* operations */ })

B. dataSource.startTransaction(() => { /* operations */ })

C. dataSource.begin(async () => { /* operations */ })

D. dataSource.runTransaction(() => { /* operations */ })

Solution

1. Step 1: Recall TypeORM transaction method

   TypeORM uses dataSource.transaction with an async callback to run transactional code.

2. Step 2: Check method names

   Only dataSource.transaction(async (manager) => { /* operations */ }) uses the correct method name and async callback pattern.

3. Final Answer:

   dataSource.transaction(async (manager) => { /* operations */ }) -> Option A

4. Quick Check:

   Correct method is transaction with async callback [OK]

Hint: Use dataSource.transaction with async callback [OK]

Common Mistakes:

• Using non-existent methods like startTransaction
• Omitting async keyword in callback
• Using wrong method names like begin or runTransaction

3. Given the following code snippet in a NestJS service using TypeORM, what will be the output if the second operation fails?

await dataSource.transaction(async (manager) => {
  await manager.save(user1);
  await manager.save(user2); // throws error
});
console.log('Transaction complete');

medium

A. Neither user1 nor user2 are saved, and an error is thrown before logging

B. Only user1 is saved, then 'Transaction complete' is logged

C. Both user1 and user2 are saved, then 'Transaction complete' is logged

D. 'Transaction complete' is logged before any save operations

Solution

1. Step 1: Understand transaction rollback behavior

   If any operation inside the transaction fails, all changes are rolled back, so no data is saved.

2. Step 2: Analyze the code flow

   The second save throws an error, so the transaction aborts and neither user1 nor user2 are saved. The error prevents reaching the console.log.

3. Final Answer:

   Neither user1 nor user2 are saved, and an error is thrown before logging -> Option A

4. Quick Check:

   Transaction rollback on error = no saves, error thrown [OK]

Hint: Error inside transaction rolls back all changes [OK]

Common Mistakes:

• Assuming partial saves happen before error
• Thinking console.log runs despite error
• Believing transaction commits despite failure

4. Identify the error in this NestJS transaction code snippet:

await dataSource.transaction(async (manager) => {
  manager.save(user1);
  await manager.save(user2);
});

medium

A. dataSource.transaction requires a synchronous callback

B. Transaction callback should not be async

C. Missing await before manager.save(user1)

D. manager.save cannot be used inside transactions

Solution

1. Step 1: Check async calls inside transaction

   All asynchronous operations inside the transaction callback must be awaited to ensure proper execution order.

2. Step 2: Identify missing await

   The first save call lacks await, so it may not complete before the second save starts, causing unexpected behavior.

3. Final Answer:

   Missing await before manager.save(user1) -> Option C

4. Quick Check:

   Await all async DB calls inside transaction [OK]

Hint: Always await async DB calls inside transaction [OK]

Common Mistakes:

• Omitting await on async calls
• Thinking transaction callback can't be async
• Believing manager.save is disallowed in transactions

5. You want to update two related entities atomically in NestJS using TypeORM transactions. Which approach correctly ensures both updates succeed or fail together?

async updateEntities(entityA, entityB) {
  await this.dataSource.transaction(async (manager) => {
    await manager.save(entityA);
    await manager.save(entityB);
  });
}

What is the best practice to handle errors and maintain data consistency?

hard

A. Manually call rollback() inside the transaction callback on error

B. Save entities without transactions and rely on database constraints

C. Use separate transactions for each save to isolate failures

D. Wrap the transaction call in try-catch and handle rollback automatically

Solution

1. Step 1: Understand transaction error handling in TypeORM

   TypeORM automatically rolls back if an error is thrown inside the transaction callback.

2. Step 2: Use try-catch outside transaction to handle errors

   Wrapping the transaction call in try-catch lets you catch errors and respond without manual rollback calls.

3. Final Answer:

   Wrap the transaction call in try-catch and handle rollback automatically -> Option D

4. Quick Check:

   Try-catch outside transaction handles errors; rollback is automatic [OK]

Hint: Use try-catch around transaction; rollback is automatic [OK]

Common Mistakes:

• Trying to manually rollback inside transaction callback
• Using separate transactions for related updates
• Ignoring transactions and relying only on DB constraints