Transaction Management practice questions

Worked examples for Transaction Management

1. Question 1

   By default, which TWO categories of throwable does Spring's declarative transaction management mark the transaction for rollback on? Select TWO.

   1. A. RuntimeException and its subclasses (unchecked exceptions)Correct answer

      An unchecked RuntimeException is the primary default rollback trigger: when one propagates out of the advised method, the transaction is marked rollback-only without any extra configuration.

   2. B. Error and its subclasses (for example OutOfMemoryError)Correct answer

      The default rule rolls back on Error as well as on RuntimeException — both are unchecked throwables, and either one propagating out of the method marks the transaction for rollback.

   3. C. Checked exceptions such as IOException or SQLException

      By default a checked exception lets the transaction commit rather than roll back; you must opt in explicitly with @Transactional(rollbackFor = ...) to make a checked exception trigger rollback.

   4. D. Any exception type named in a noRollbackFor attribute

      noRollbackFor does the opposite of triggering rollback: it removes the listed exception types from the rollback set so the transaction commits despite them.

   Explanation

   By default Spring's declarative transactions roll back on unchecked throwables: a RuntimeException (or any subclass) and an Error (or any subclass) each mark the transaction rollback-only when they propagate out of the advised method. A checked exception instead lets the transaction commit unless you opt in with @Transactional(rollbackFor = ...), and the noRollbackFor attribute removes exception types from the rollback set rather than adding them, so it never causes a rollback.

2. Question 2

   In a non-Boot Java-config application, what activates processing of @Transactional annotations?

   1. A. @EnableJpaRepositories

      @EnableJpaRepositories configures Spring Data JPA repository scanning, not the @Transactional advisor and proxy infrastructure.

   2. B. @EnableTransactionManagement on a @Configuration classCorrect answer

      @EnableTransactionManagement registers the infrastructure (advisor plus proxy creator) that makes @Transactional effective; Spring Boot enables this automatically, but a plain Java-config app must declare it.

   3. C. @Transactional self-activates the infrastructure

      @Transactional is inert on its own; without the enabling annotation no advisor or proxy is registered, so the annotation has no effect.

   4. D. Nothing — @Transactional is always processed

      @Transactional is not always processed; a non-Boot application must explicitly enable transaction management for the annotation to be honored.

   Explanation

   In a non-Boot Java-config application the @Transactional annotation only takes effect once the transaction management infrastructure — the advisor and the proxy creator — is explicitly registered on a configuration class. Until that happens the annotation is inert, and repository-scanning or persistence-configuration annotations do not supply it.

3. Question 3

   How does Propagation.SUPPORTS behave?

   1. A. It throws an exception if no transaction exists

      Throwing when no transaction is active is the behavior of MANDATORY, not SUPPORTS, which tolerates the absence of a transaction.

   2. B. It always starts a new transaction

      Always starting a new transaction describes REQUIRES_NEW; SUPPORTS never forces a new transaction into existence.

   3. C. It runs within a transaction if one already exists, otherwise it runs non-transactionallyCorrect answer

      SUPPORTS participates in an existing transaction but does not require one, running non-transactionally when none is active.

   4. D. It always suspends the current transaction

      Always suspending an active transaction to run non-transactionally is the behavior of NOT_SUPPORTED, whereas SUPPORTS joins an active transaction when present.

   Explanation

   SUPPORTS is the permissive propagation mode: it participates in a transaction when one is already active but does not demand one, running non-transactionally otherwise. It neither forces a new transaction, nor fails when none exists, nor suspends an existing one.

4. Question 4

   Under Spring's default declarative-transaction settings, a @Transactional method throws a java.lang.Error (for example an AssertionError) that propagates out of the method. Is the transaction committed or rolled back?

   1. A. Rolled back — the default rule rolls back on both RuntimeException and Error, and an Error is one of the two unchecked throwable categories that trigger rollback.Correct answer

      Spring's default rollback rule covers RuntimeException and Error alike, so an Error propagating out of the method marks the transaction for rollback with no extra configuration.

   2. B. Committed, because only RuntimeException triggers the default rollback and an Error is not a RuntimeException.

      The default rule includes Error in addition to RuntimeException, so an Error does roll back rather than commit.

   3. C. Committed, because Error is not a subclass of Exception and only Exception subtypes are considered.

      Rollback selection is not limited to Exception subtypes; Error is explicitly part of the default rollback set even though it is not an Exception.

   4. D. It depends on rollbackFor; without it, an Error is ignored by the transaction infrastructure.

      No extra rollbackFor entry is needed for an Error to roll back — it is included in the default rule already.

   Explanation

   The default rule rolls back on unchecked throwables, which means both RuntimeException and Error, so an Error escaping the method rolls the transaction back without any configuration. The common trap is to assume only RuntimeException (or only Exception subtypes) counts; Error is deliberately included, and no rollbackFor entry is required to cover it.

5. Question 5

   You want a transaction to roll back when a specific CHECKED exception is thrown. How do you configure it?

   1. A. Nothing — checked exceptions already roll back by default

      By default checked exceptions do NOT trigger rollback; only unchecked exceptions do, so doing nothing leaves the transaction committing on a checked exception.

   2. B. Re-throw it wrapped as a RuntimeException; rollbackFor does not exist

      rollbackFor is a real @Transactional attribute, so wrapping the checked exception as a RuntimeException is unnecessary to force rollback.

   3. C. @Transactional(rollbackFor = OrderProcessingException.class)Correct answer

      rollbackFor opts a checked exception into rollback behavior, which by default applies only to unchecked exceptions.

   4. D. @Transactional(noRollbackFor = OrderProcessingException.class)

      noRollbackFor does the opposite of what is wanted: it suppresses rollback for the named exception rather than triggering it.

   Explanation

   By default Spring rolls back only on unchecked exceptions, so a checked exception must be explicitly opted in for rollback. The attribute that adds an exception type to the rollback set is the correct tool, whereas the attribute that removes types from that set would produce the opposite behavior.

6. Question 6

   What component actually drives begin/commit/rollback behind @Transactional at runtime?

   1. A. Spring always uses a JTA global transaction manager

      JTA is only used for multi-resource/global transactions, not always; for a single JDBC or JPA resource Spring uses a resource-local manager instead.

   2. B. A BeanFactoryPostProcessor

      A BeanFactoryPostProcessor customizes bean definitions during context startup and is unrelated to driving begin/commit/rollback at runtime.

   3. C. The JDBC driver on its own

      The driver alone does not provide Spring's transaction abstraction; Spring's infrastructure must delegate to a transaction manager that coordinates the resource.

   4. D. A PlatformTransactionManager implementation (e.g. DataSourceTransactionManager or JpaTransactionManager)Correct answer

      The transaction infrastructure delegates to a PlatformTransactionManager appropriate to the resource (DataSourceTransactionManager for JDBC, JpaTransactionManager for JPA), which actually performs begin/commit/rollback.

   Explanation

   Behind @Transactional, Spring's declarative infrastructure delegates the actual begin/commit/rollback work to a PlatformTransactionManager strategy chosen for the underlying resource. This abstraction is what integrates with the resource, rather than the raw driver or startup-time bean processors, and a global JTA manager is engaged only when spanning multiple resources.

7. Question 7

   A Spring bean has two public methods. `placeOrder()` carries no transaction annotation and, inside its body, calls `this.saveAudit()`. `saveAudit()` is annotated `@Transactional(propagation = Propagation.REQUIRES_NEW)`. The application uses Spring's default proxy-based declarative transaction management with `@EnableTransactionManagement`. When an external caller invokes `placeOrder()`, the audit work runs with no transaction at all. What is the reason?

   1. A. `REQUIRES_NEW` can only suspend and replace an already-running transaction; because `placeOrder()` is not transactional there is nothing to suspend, so the annotation has no effect.

      Misconception that REQUIRES_NEW depends on an outer transaction. REQUIRES_NEW always starts a new transaction, suspending an existing one only if one happens to be active — invoked through the proxy from a non-transactional caller it would still begin a transaction.

   2. B. Spring detects `@Transactional` only on methods declared in an interface that the bean implements; because `saveAudit()` is not part of such an interface, no transactional advice is created for it.

      Misconception that the annotation must sit on an interface method. Spring reads @Transactional on the implementation class as well (and the reference documentation actually recommends annotating concrete classes), so interface membership is not what decides advice here.

   3. C. The call to `saveAudit()` is a self-invocation that goes directly through `this`, so it never passes through the transactional proxy that would have applied the advice.Correct answer

      Correct: in the proxy-based model the interceptor lives on the proxy, and only calls arriving from outside the bean go through it. A `this.` call inside the target object bypasses the proxy entirely, so no transaction is started, exactly as the self-invocation caveat in the declarative transaction management documentation describes.

   4. D. Transactional advice is applied only to the first bean method invoked in a given request; every nested annotated method inherits the caller's transactional state instead of being advised again.

      Misconception that advice fires once per request or per call stack. There is no such once-per-request rule — a nested call that genuinely crosses a proxy boundary is advised again and its propagation setting is honoured.

   Explanation

   Spring's declarative transaction management is proxy-based: the transaction interceptor is attached to a proxy that wraps the target bean, so transactional semantics apply only when a call enters the bean through that proxy. An internal call made on `this` reaches the target object directly, the interceptor never runs, and the annotation's propagation setting is simply not consulted — the documented self-invocation caveat. The propagation type is irrelevant to this outcome, since REQUIRES_NEW starts a transaction whether or not one is already active; annotating the concrete class rather than an interface is fully supported and does not suppress advice; and there is no rule limiting advice to the first method invoked per request, as any call that genuinely crosses the proxy boundary is advised. Routing the call through the injected proxy (or switching to AspectJ weaving) restores the expected behaviour.

8. Question 8

   What is the default propagation behavior of @Transactional, and what does it do?

   1. A. SUPPORTS — run non-transactionally unless a transaction already exists

      SUPPORTS is a valid propagation mode but not the default; it runs without a transaction when none is active rather than creating one, so it must be requested explicitly.

   2. B. MANDATORY — throw an exception if no transaction is already active

      MANDATORY is a valid mode but not the default; it refuses to run and throws when no caller-supplied transaction exists instead of starting one, and it must be requested explicitly.

   3. C. REQUIRED — join the current transaction if one exists, otherwise start a new oneCorrect answer

      This is the default, Propagation.REQUIRED: the method participates in an existing transaction or creates one if none is active.

   4. D. REQUIRES_NEW — always suspend any existing transaction and start a fresh one

      REQUIRES_NEW is a valid mode but not the default; it always suspends any existing transaction to run in its own and must be requested explicitly.

   Explanation

   Spring's @Transactional defaults to Propagation.REQUIRED, meaning a method joins whatever transaction is already active and only opens a new one when none exists. The other propagation modes are all legitimate but each must be selected deliberately because they change whether a transaction is reused, newly created, or required up front.