@Transactional Semantics in Spring

`@Transactional` defines a transactional boundary around Spring-managed method execution and lets Spring apply transaction behavior declaratively. It typically controls when a transaction starts, commits, or rolls back, subject to the configured transaction manager and propagation rules.

When a Spring-managed method is annotated with `@Transactional`, Spring can intercept the method call and execute it within a database transaction. The transaction is normally started before the method body and completed afterward by committing or rolling back as appropriate.

By default, Spring rolls back a transaction for an unchecked exception such as `RuntimeException` or `Error`, while checked exceptions do not normally trigger rollback. This behavior can be customized with attributes such as `rollbackFor` and `noRollbackFor`.

`@Transactional` also supports propagation, which determines how a method participates in an existing transaction. The common default, `REQUIRED`, joins an existing transaction or creates one when none exists. Other propagation modes can suspend, require, or avoid transactions depending on the use case.

The annotation is commonly applied through Spring's proxy-based infrastructure. Consequently, calls that bypass the proxy, such as a method calling another `@Transactional` method on the same instance, may not receive the expected transactional interception.

Transaction behavior also depends on the configured transaction manager and resource. In a typical Spring application using a relational database, the transaction manager coordinates the database connection and transaction lifecycle; `@Transactional` itself is not a database transaction implementation.

Key points

• `@Transactional` declares a transactional boundary for Spring-managed method execution.
• Default propagation is `REQUIRED`: join an existing transaction or create one.
• Unchecked exceptions normally cause rollback; checked exceptions normally do not.
• Transactional behavior is commonly applied through Spring proxies.
• The configured transaction manager determines how the transaction is actually coordinated.

Interview questions

What does `@Transactional` do in Spring?

It tells Spring to execute a method within a transaction. Spring's transaction infrastructure starts or joins a transaction before the method and commits or rolls it back afterward. The exact behavior depends on the transaction manager and annotation settings.

What is the default rollback behavior of `@Transactional`?

By default, Spring rolls back when the transactional method throws an unchecked exception, meaning a `RuntimeException` or `Error`. Checked exceptions do not normally cause rollback by default. You can change the rule with attributes such as `rollbackFor`.

What does `Propagation.REQUIRED` mean?

`REQUIRED` is the default propagation behavior. If the caller already has a transaction, the method participates in that transaction. If there is no existing transaction, Spring creates one for the method.

Why might `@Transactional` not work during self-invocation?

Spring commonly applies `@Transactional` through a proxy around the managed bean. A call from one method directly to another method on the same object can bypass that proxy. As a result, the second method's transactional annotation may not be intercepted as expected.

Does `@Transactional` make an operation atomic across a database and an external API?

Not by itself. A database transaction can coordinate the database resources managed by the transaction infrastructure, but an external HTTP service is not automatically part of that same transaction. If the database commits and the external call fails, or vice versa, the operations can become inconsistent. Coordinating multiple systems usually requires a broader distributed-consistency strategy such as an outbox pattern or an appropriate distributed transaction mechanism.