Declarative Transaction Management with @Transactional

1. From Programmatic to Declarative Transactions

Before Spring, managing database transactions in Java required explicit, often repetitive, code. You would manually get a connection, disable auto-commit, wrap your database operations in a try/catch block, and then explicitly call commit() or rollback().

Connection connection = null;
try {
    connection = dataSource.getConnection();
    connection.setAutoCommit(false); // Start transaction

    // ... execute your SQL statements ...

    connection.commit(); // Commit transaction
} catch (SQLException e) {
    if (connection != null) {
        try {
            connection.rollback(); // Rollback on error
        } catch (SQLException ex) {
            // log rollback failure
        }
    }
    // handle exception
} finally {
    if (connection != null) {
        try {
            connection.close();
        } catch (SQLException e) {
            // log close failure
        }
    }
}

This is called programmatic transaction management. As you can imagine, this boilerplate code clutters your business logic and is prone to error.

Spring introduced declarative transaction management, where you simply declare that a method should run inside a transaction, and Spring handles the rest. The primary tool for this is the @Transactional annotation.

2. How @Transactional Works: A Look Under the Hood

This declarative approach feels like magic, but for an interview, you need to explain the mechanism behind it. The magic is accomplished through Aspect-Oriented Programming (AOP) and dynamic proxies.

When Spring detects a bean with a @Transactional annotation on a public method, it doesn't just create an instance of your class. Instead, it creates a proxy object that wraps your bean. When another component calls your method, it's actually calling the proxy.

The proxy's job is to:

1. Intercept the method call.
2. Begin a transaction (by interacting with a PlatformTransactionManager).
3. Invoke the actual method on your bean.
4. If the method completes successfully, the proxy commits the transaction.
5. If the method throws a runtime exception, the proxy rolls back the transaction.

This video also provides a great conceptual walkthrough of the proxy's logic.

3. Understanding Transaction Propagation

Now we get to the core of this lesson. What happens when a @Transactional method calls another @Transactional method? Does it join the existing transaction, or start a new one? This behavior is controlled by the propagation level.

First, it's vital to distinguish between a physical and a logical transaction.

• Physical Transaction: The actual transaction with the database, controlled by the JDBC connection (connection.commit(), connection.rollback()).
• Logical Transaction: Spring's concept of a transactional scope, defined by the boundaries of a @Transactional method.

One physical transaction can span multiple logical transactions. The propagation level determines how these logical transaction scopes relate to each other and to the underlying physical transaction.

Propagation.REQUIRED (The Default)

This is the most common propagation level. Its rule is simple:

Support a current transaction; create a new one if none exists.

If methodA() calls methodB(), and both are marked @Transactional(propagation = Propagation.REQUIRED):

• If methodA() was called and started a new physical transaction, methodB() will join that same physical transaction.
• If methodA() did not have a transaction, a new physical transaction would have been created for it, and methodB() would join it.

The entire operation commits or rolls back as a single unit. If methodB() fails, the entire transaction started by methodA() is marked for rollback.

Propagation.REQUIRES_NEW

This propagation level is used for operations that need to be independent. Its rule is:

Create a new transaction, and suspend the current transaction if one exists.

If methodA() calls methodB(), and methodB() is marked @Transactional(propagation = Propagation.REQUIRES_NEW):

• The transaction of methodA() is paused (suspended).
• A completely new physical transaction is started for methodB().
• methodB() executes. Its transaction either commits or rolls back, completely independently of methodA().
• The transaction of methodA() is resumed.

Interview Insight: A common use case for REQUIRES_NEW is for non-critical, secondary operations like auditing or logging. You want to log an action to the database even if the main business transaction fails. If the logging fails, you don't want it to cause the main business transaction to roll back.

Visualizing Propagation Levels

This can be tricky to visualize, so here is an excellent diagram that summarizes the behavior of different propagation levels. Focus on REQUIRED and REQUIRES_NEW.

Other Propagation Levels

While REQUIRED and REQUIRES_NEW are the most common, you should be aware that others exist:

• SUPPORTS: Executes within a transaction if one is present, otherwise executes non-transactionally.
• MANDATORY: Throws an exception if there is no active transaction.
• NOT_SUPPORTED: Executes non-transactionally, suspending any current transaction.
• NEVER: Throws an exception if a transaction is active.
• NESTED: Starts a "nested" transaction using JDBC savepoints if a transaction is active, otherwise behaves like REQUIRED. This allows for partial rollbacks within a larger transaction.

4. Interview Focus: The Self-Invocation Pitfall

One of the most common interview traps related to @Transactional is the self-invocation problem.

Consider this code:

@Service
public class MyService {

    public void methodA() {
        // ... some logic ...
        this.methodB(); // Calling another method in the SAME class
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void methodB() {
        // ... database logic ...
    }
}

You might expect methodB to run in a new transaction. It will not.

Why? Remember the proxy? The transactional behavior is added by the proxy that wraps MyService. When an external class calls myService.methodA(), it goes through the proxy. However, when methodA() calls this.methodB(), it's making a direct internal call to the original object, completely bypassing the proxy. Since the proxy is bypassed, there is no code to intercept the call and apply the REQUIRES_NEW propagation behavior.

This is a hallmark of a deep understanding of Spring's inner workings and a great point to bring up in an interview to demonstrate your expertise.

Conclusion

Today you've learned how Spring's declarative transaction management simplifies data integrity and how to control its behavior with propagation levels. This is a fundamental skill that separates robust, predictable applications from brittle ones.

Key Takeaways:

• Declarative vs. Programmatic: @Transactional allows you to declare transactional boundaries, which is far cleaner and safer than managing them programmatically.
• Proxies are the Key: Spring uses AOP and dynamic proxies to wrap your beans and inject transactional logic (begin, commit, rollback) around your method calls.
• Propagation Controls Behavior: The propagation level dictates what happens when one transactional method calls another.
  • REQUIRED (default): Joins the current transaction or starts a new one. All work is part of one atomic unit.
  • REQUIRES_NEW: Always starts a new, independent transaction. Useful for isolating operations like auditing or logging.
• Beware of Self-Invocation: Calling a @Transactional method from within the same class (this.someMethod()) bypasses the proxy, meaning the transactional annotation on the called method will have no effect.

Preview of the Next Lesson:
We've now mastered how to define the scope (@Transactional) and propagation of our transactions. But what happens when multiple transactions try to access the same data at the same time? In our next lesson, we will dive into transaction isolation levels and their critical role in preventing concurrency issues like dirty reads, non-repeatable reads, and phantom reads.