Transaction management with @Transactional in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a RuntimeException is thrown inside a @Transactional method?

Consider a Spring Boot service method annotated with @Transactional. If this method throws a RuntimeException, what will be the outcome regarding the transaction?

Spring Boot

public void updateData() {
  // some database operations
  if(someCondition) {
    throw new RuntimeException("Error occurred");
  }
}

A The transaction commits successfully despite the exception.

B The transaction is rolled back automatically.

C The transaction is paused and resumed after handling the exception.

D The transaction commits but logs the exception.

💡 Hint

Think about Spring's default rollback behavior for unchecked exceptions.

By default, Spring rolls back transactions when a RuntimeException or Error is thrown inside a @Transactional method. Checked exceptions do not trigger rollback unless configured.

📝 Syntax

intermediate

Which @Transactional annotation usage is correct to rollback on a checked exception?

You want a transaction to rollback when a checked exception IOException occurs. Which annotation usage is correct?

A @Transactional(rollbackFor = IOException.class)

B @Transactional(noRollbackFor = IOException.class)

C @Transactional(rollbackOn = IOException.class)

D @Transactional(rollback = IOException.class)

💡 Hint

Check the exact attribute name for rollback exceptions in @Transactional.

The rollbackFor attribute specifies exceptions that should trigger rollback, including checked exceptions like IOException. Other options are invalid attributes.

🔧 Debug

advanced

Why does the transaction not rollback when a checked exception is thrown?

A method annotated with @Transactional throws a checked exception, but the transaction commits instead of rolling back. What is the most likely cause?

Spring Boot

public void process() throws IOException {
  // database update
  throw new IOException("Checked exception");
}

A The exception is caught and handled inside the method.

B The method is missing the <code>@Transactional</code> annotation.

C The database connection is not configured for transactions.

D Spring does not rollback transactions for checked exceptions by default.

💡 Hint

Recall Spring's default rollback rules for checked vs unchecked exceptions.

Spring only rolls back transactions automatically for unchecked exceptions (RuntimeException and Error) by default. Checked exceptions require explicit rollback configuration.

🧠 Conceptual

advanced

What is the effect of calling a @Transactional method from another method in the same class?

In Spring Boot, if a @Transactional method is called from another method within the same class, what happens to the transaction behavior?

A The transaction is ignored and an error is thrown.

B The transaction starts and commits normally.

C The transaction is not applied because Spring proxies do not intercept internal method calls.

D The transaction is applied twice causing nested transactions.

💡 Hint

Think about how Spring AOP proxies work with self-invocation.

Spring uses proxies to apply transactions. Internal calls within the same class bypass the proxy, so @Transactional is ignored in that case.

❓ state_output

expert

What is the final database state after nested @Transactional methods with different propagation?

Given two methods: outerMethod() annotated with @Transactional(propagation = Propagation.REQUIRED) and innerMethod() annotated with @Transactional(propagation = Propagation.REQUIRES_NEW). If innerMethod() throws a RuntimeException but outerMethod() catches it and completes normally, what is the final state of the database?

Spring Boot

public void outerMethod() {
  try {
    innerMethod();
  } catch (RuntimeException e) {
    // handle exception
  }
  // continue with other DB operations
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void innerMethod() {
  // DB insert
  throw new RuntimeException("Fail");
}

A Changes in innerMethod are rolled back; changes in outerMethod are committed.

B All changes from both methods are rolled back.

C All changes from both methods are committed.

D Changes in innerMethod are committed; outerMethod changes are rolled back.

💡 Hint

Consider how REQUIRES_NEW creates a separate transaction independent of the outer one.

Propagation.REQUIRES_NEW starts a new transaction. When innerMethod throws an exception, its transaction rolls back. The outer transaction continues and commits normally.

Practice

1. What is the main purpose of using @Transactional in a Spring Boot application?

easy

A. To ensure multiple database operations are executed as a single unit and rollback on failure

B. To speed up database queries by caching results

C. To automatically generate database schema from entities

D. To log all database queries for debugging

Solution

1. Step 1: Understand the role of @Transactional

   @Transactional groups multiple database operations so they succeed or fail together.

2. Step 2: Identify the effect on data consistency

   If any operation fails, all changes are rolled back to keep data correct.

3. Final Answer:

   To ensure multiple database operations are executed as a single unit and rollback on failure -> Option A

4. Quick Check:

   @Transactional = atomic database actions [OK]

Hint: Think: all-or-nothing for database changes [OK]

Common Mistakes:

• Confusing @Transactional with caching or logging
• Thinking it speeds up queries
• Assuming it auto-generates schema

2. Which of the following is the correct way to apply @Transactional to a method in a Spring Boot service class?

easy

A. @Transactional public void updateData() { ... }

B. public @Transactional void updateData() { ... }

C. public void updateData() @Transactional { ... }

D. public void updateData() { @Transactional ... }

Solution

1. Step 1: Recall correct annotation placement

   Annotations like @Transactional go before the method signature.

2. Step 2: Check each option's syntax

   @Transactional public void updateData() { ... } places @Transactional correctly before the method declaration.

3. Final Answer:

   @Transactional public void updateData() { ... } -> Option A

4. Quick Check:

   Annotation before method = correct syntax [OK]

Hint: Annotations always go before method signature [OK]

Common Mistakes:

• Placing annotation inside method body
• Putting annotation after method signature
• Using annotation as a modifier keyword

3. Consider this Spring Boot service method annotated with @Transactional:

@Transactional
public void saveUserAndAccount(User user, Account account) {
    userRepository.save(user);
    accountRepository.save(account);
    if(account.getBalance() < 0) {
        throw new RuntimeException("Negative balance not allowed");
    }
}

What happens if account.getBalance() < 0 is true during execution?

medium

A. An error is logged but changes are committed

B. Only the user is saved, account save is rolled back

C. Both user and account are saved to the database

D. Neither user nor account is saved; transaction rolls back

Solution

1. Step 1: Understand rollback behavior of @Transactional

   By default, RuntimeExceptions cause the transaction to rollback all changes.

2. Step 2: Analyze the exception thrown

   The method throws RuntimeException if balance is negative, triggering rollback.

3. Final Answer:

   Neither user nor account is saved; transaction rolls back -> Option D

4. Quick Check:

   RuntimeException triggers rollback = no data saved [OK]

Hint: Exception inside @Transactional rolls back all changes [OK]

Common Mistakes:

• Assuming partial saves happen
• Thinking only last save rolls back
• Ignoring exception effect on transaction

4. Given this method in a Spring Boot service:

@Transactional
public void updateRecords() {
    recordRepository.updateA();
    recordRepository.updateB();
    // Missing exception handling
}

If updateB() throws a checked exception (not RuntimeException), what will happen to the transaction?

medium

A. Transaction will rollback automatically

B. Transaction will commit despite the exception

C. Transaction will rollback only if exception is caught and rethrown as RuntimeException

D. Transaction will pause until exception is handled

Solution

1. Step 1: Recall default rollback rules of @Transactional

   By default, only unchecked exceptions (RuntimeException) cause rollback.

2. Step 2: Analyze checked exception behavior

   Checked exceptions do not trigger rollback unless configured or rethrown as RuntimeException.

3. Final Answer:

   Transaction will commit despite the exception -> Option B

4. Quick Check:

   Checked exceptions do not rollback by default [OK]

Hint: Only RuntimeExceptions rollback by default [OK]

Common Mistakes:

• Assuming all exceptions cause rollback
• Not knowing difference between checked and unchecked exceptions
• Expecting rollback without configuration

5. You have a Spring Boot service with two methods:

public void outerMethod() {
    innerMethod();
}

@Transactional
public void innerMethod() {
    // database updates
    if(someCondition) throw new RuntimeException();
}

If outerMethod() is called, will the transaction rollback if innerMethod() throws the exception? Assume default proxy-based Spring transaction management.

hard

A. Yes, but only if outerMethod is also annotated with @Transactional

B. Yes, transaction rolls back because innerMethod is @Transactional

C. No, transaction does not rollback because outerMethod is not @Transactional and calls innerMethod internally

D. No, because RuntimeException does not trigger rollback in this case

Solution

1. Step 1: Understand Spring proxy behavior for @Transactional

   Spring uses proxies, so self-invocation (method calling another in same class) bypasses proxy and ignores @Transactional.

2. Step 2: Analyze effect on transaction rollback

   Since outerMethod calls innerMethod directly, @Transactional on innerMethod is ignored, so no transaction starts and no rollback occurs.

3. Final Answer:

   No, transaction does not rollback because outerMethod is not @Transactional and calls innerMethod internally -> Option C

4. Quick Check:

   Self-call bypasses @Transactional proxy = no rollback [OK]

Hint: Self-calls ignore @Transactional proxy, no transaction started [OK]

Common Mistakes:

• Assuming @Transactional always works on internal calls
• Thinking RuntimeException always triggers rollback here
• Not knowing Spring proxy limitations