Spring Boot Database Transactions u0026 Error Handling Essentials Quiz Quiz

Explore foundational concepts of Spring Boot database transactions and error handling with these essential questions. This quiz covers transactional propagation, rollback strategies, exception types, annotation usage, and practical error management techniques for robust Spring Boot applications.

1. Basic Transaction Annotation

   Which annotation is typically used to declare a transactional method in a Spring Boot service class?

   1. @Transactional
   2. @Database
   3. @Persisted
   4. @Connection

   Explanation: The @Transactional annotation is used to indicate that a method should run within a database transaction. The other options, such as @Persisted, @Connection, and @Database, are not valid transaction-related annotations in this context. Using @Transactional ensures that the method’s actions are atomic, consistent, isolated, and durable.

2. Default Transaction Rollback Behavior

   By default, a Spring Boot transaction rolls back when which type of exception is thrown?

   1. A null pointer exception only
   2. A runtime exception or error
   3. Any checked exception
   4. Only SQLSyntaxErrorException

   Explanation: By default, transactions rollback on runtime exceptions or errors, helping avoid inconsistent database states. Checked exceptions do not cause a rollback unless explicitly specified. Only rolling back on specific exceptions like SQLSyntaxErrorException or null pointer exception is not the standard default behavior.

3. Transaction Propagation Example

   If a method declared as transactional calls another transactional method with propagation set to REQUIRES_NEW, what happens to their transactions?

   1. The called method starts a new, independent transaction
   2. Both methods share the same transaction
   3. The called method executes without any transaction
   4. The outer transaction is paused and does not resume

   Explanation: REQUIRES_NEW propagation starts a fresh transaction, suspending the outer transaction until the inner one finishes. Sharing the same transaction happens with the default (REQUIRED) propagation. Running without a transaction or pausing the outer transaction indefinitely are incorrect descriptions.

4. Transactional Read-Only Optimization

   What is the purpose of setting 'readOnly=true' in the @Transactional annotation for a method that retrieves data?

   1. To optimize query performance and prevent accidental modifications
   2. To force the method to use a writable connection
   3. To ensure the data is updated after every read
   4. To prevent the method from reading any data

   Explanation: Setting 'readOnly=true' signals the database that data modification is not expected, possibly allowing transaction optimizations and safeguarding against accidental updates. It does not block data reads—rather, it still allows querying. It does not force updates or require a writable connection for reads, which would be unnecessary.

5. Exception Impact on Transactions

   A service method annotated with @Transactional throws a custom checked exception by default. What happens to the transaction?

   1. The transaction is committed
   2. The transaction is always rolled back
   3. The transaction is suspended
   4. The application restarts

   Explanation: By default, only runtime exceptions or errors trigger rollback, so if a method throws a checked exception with no additional configuration, the transaction is committed. Rollback is not always triggered for checked exceptions. Transaction suspension or application restart are unrelated actions and do not normally occur in this scenario.

6. Declaring Rollback for Checked Exceptions

   How can you specify that a Spring Boot transaction should roll back on a specific checked exception?

   1. Use @ExceptionHandler on the class
   2. Declare the exception in the method's throws clause
   3. Set readOnly=true in @Transactional
   4. Set the rollbackFor attribute in the @Transactional annotation

   Explanation: The rollbackFor attribute within @Transactional can be set to a checked exception class to trigger a rollback when that exception is thrown. Declaring exceptions in the throws clause does not affect transaction behavior. The readOnly attribute is unrelated, and @ExceptionHandler is used for handling, not transactional rollback.

7. Transaction Isolation Level Purpose

   Why might you specify an isolation level, such as Isolation.SERIALIZABLE, on a transactional method in Spring Boot?

   1. To reduce server memory usage
   2. To improve method readability
   3. To log SQL queries
   4. To control data consistency and prevent anomalies

   Explanation: Isolation levels define how transaction integrity is maintained, preventing issues like dirty, non-repeatable, or phantom reads. Logging SQL or reducing memory are not purposes of isolation settings. Method readability is not affected by the isolation level configuration.

8. Handling Database Errors in Spring Boot

   When a database constraint violation occurs in a Spring Boot application, which approach helps handle the exception and inform the user gracefully?

   1. Show the entire stack trace to the user
   2. Silently ignore the exception
   3. Catch the exception and return a user-friendly message
   4. Restart the database connection every time

   Explanation: Catching exceptions and providing clear, helpful feedback to users is a best practice for good user experience and maintainability. Silently ignoring errors leads to hidden bugs. Restarting the connection is unnecessary and inefficient. Displaying stack traces exposes internal details and is not user-friendly.

9. Purpose of @ExceptionHandler Annotation

   What is the primary use of the @ExceptionHandler annotation in a Spring Boot controller?

   1. To handle database persistence
   2. To define methods that handle specific exceptions and customize responses
   3. To monitor database transactions in real time
   4. To schedule background tasks

   Explanation: @ExceptionHandler is used to define methods that capture specific exceptions thrown by controller methods, allowing for custom response messages. It is not intended for persistence logic, task scheduling, or monitoring transactions. Its main function is error handling within the web layer.

10. Transactional Boundaries in Nested Methods

    If a non-transactional method calls a transactional method, what happens to the transactional boundaries of the called method?

    1. The transactional method runs within a new transaction
    2. Both methods must be annotated as transactional for any transaction to start
    3. No transaction is created, so changes are not committed
    4. The outer method determines the transaction status

    Explanation: A method annotated as transactional will start a transaction when invoked, even if the calling method is not transactional. No transaction would result in changes not being committed, which is incorrect. Both methods do not have to be transactional, and the outer method does not dictate the transaction unless it is transactional itself.