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.