Spring Boot Transaction Management

Why Do We Need Transaction Management?

Transaction management is essential in database operations to ensure data consistency, integrity, and reliability. Let’s understand the importance of transaction management with an easy example:

Example: Online Banking Transfer

Imagine you’re transferring money from one bank account to another using an online banking application. This process involves multiple steps, such as deducting funds from your account and crediting them to the recipient’s account. Let’s see what could happen without transaction management:

Without Transaction Management:

• Step 1: Deduct funds from your account.
• Step 2: Credit funds to the recipient’s account.

Now, imagine if an error occurs after Step 1 (e.g., server crash, network issue). Your account would be deducted, but the recipient’s account wouldn’t be credited. This inconsistency could lead to financial discrepancies and customer dissatisfaction.

2. With Transaction Management:

• Step 1: Begin transaction.
• Step 2: Deduct funds from your account.
• Step 3: Credit funds to the recipient’s account.
• Step 4: Commit transaction.

If an error occurs at any step, the transaction can be rolled back, ensuring that no changes are applied to the database. This way, both deducting funds from your account and crediting them to the recipient’s account are treated as a single atomic transaction. If any step fails, the entire transaction is rolled back, maintaining data consistency and integrity.

Conclusion: Transaction management is crucial in scenarios like online banking transfers, where multiple database operations must be executed as a single unit of work. It ensures that database changes are either fully applied or fully rolled back, preventing data corruption and maintaining data integrity. Without transaction management, database operations could lead to inconsistent and unreliable application behavior.

ACID

Imagine you’re transferring money from your savings account to your checking account using an online banking application. Let’s see how ACID transactions ensure the safety and integrity of this operation:

1. Atomicity: Atomicity ensures that the transfer of funds occurs as a single, indivisible unit. If anything goes wrong during the transfer, such as a network failure or system crash, the entire transaction is aborted, and both accounts remain unchanged. Your money is either fully transferred or not transferred at all, preventing partial transfers and potential loss of funds.

2. Consistency: Consistency ensures that your accounts remain in a valid state before and after the transaction. For example, if your savings account has $500 and your checking account has $200 before the transfer, the total balance across both accounts should remain the same after the transfer, ensuring that the sum of funds in your accounts remains consistent.

3. Isolation: Isolation means that the operations of one transaction are not visible to other transactions until the transaction is completed (committed) or rolled back. This ensures that intermediate states of the transaction do not affect other transactions, even when multiple transactions occur concurrently.

4. Durability: Durability ensures that once the transfer transaction is successfully completed and confirmed, the changes made to your account balances are permanent and will not be lost, even in the event of a system failure or crash. Your updated account balances are securely stored in the bank’s database, guaranteeing the durability of the transaction.

Conclusion: ACID transactions play a crucial role in ensuring the reliability, consistency, and integrity of banking operations, such as fund transfers. By adhering to the principles of atomicity, consistency, isolation, and durability, ACID transactions provide a robust framework for maintaining the safety and integrity of financial transactions in the banking industry.

Why Do We Need Transaction Management?

Imagine you’re using an online service, and you decide to book a ticket. You enter your information, like your name and email, and proceed to make a payment for the ticket.

Now, here’s where things get tricky. What if, after you’ve entered your information but before the payment is processed, something goes wrong? Maybe the system crashes, or there’s an error in processing your payment.

Without transaction management, your information would still be stored in the system, even though the ticket wasn’t booked. This could lead to inconsistencies and errors in the system’s data.

This is where transaction management comes in. It ensures that operations like storing your information and processing your payment are treated as a single unit of work, known as a transaction.

With transaction management, your information is temporarily stored in memory until the payment is successfully processed. If the payment fails for any reason, the entire transaction is rolled back, and your information is not permanently stored in the system. This helps maintain the integrity and consistency of the system’s data, even in the event of failures or errors.

So, in simple terms, transaction management ensures that all the steps involved in a task, like booking a ticket, are completed successfully or none of them are, reducing the chances of errors and inconsistencies in the system’s data.

Transactional Scope

You can apply @Transactional at class or method levels:

• Class Level: All public methods in the class will run within a transaction.

@Transactional
public class OrderService {
    public void placeOrder() {
        // This method runs inside a transaction
    }
}

Here, all methods in OrderService are transactional.

• Method Level: Only the specific method is transactional.

public class PaymentService {
    @Transactional
    public void processPayment() {
        // Only this method runs inside a transaction
    }
}

This flexibility allows you to choose the right scope based on your needs.

Propagation Behavior

Propagation determines how transactions interact with each other.

Here are some key types:

• REQUIRED (default): Joins the current transaction or creates a new one if none exists.
• REQUIRES_NEW: Always starts a new transaction, suspending any active one.
• SUPPORTS: Uses a transaction if it exists, otherwise executes without one.
• NEVER: Ensures no transaction is active; throws an error if there is one.

These settings let you handle even complex transactional scenarios effortlessly.

Rollback Behavior

By default, transactions roll back for runtime exceptions (unchecked exceptions) and errors.

You can customize this:

• rollbackFor: Specify which exceptions (e.g., checked exceptions) should trigger a rollback.
• noRollbackFor: Specify exceptions that should not trigger a rollback.

For example, you might want to save partial data even if a specific exception occurs.

Isolation Levels

Isolation levels protect your data from unwanted side effects in concurrent transactions.

Common levels include:

• READ_UNCOMMITTED: Least strict. Allows transactions to see uncommitted changes (dirty reads).
• READ_COMMITTED: Prevents dirty reads by ensuring only committed data is read.
• REPEATABLE_READ: Ensures consistent data for a transaction, even if others modify it (prevents dirty and non-repeatable reads).
• SERIALIZABLE: Most strict. Fully isolates transactions, but can impact performance.

Here’s a full example of a Spring Boot application with @Transactional annotation and transaction management enabled:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.transaction.annotation.EnableTransactionManagement;

@SpringBootApplication
@EnableTransactionManagement
public class SpringBootDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootDemoApplication.class, args);
    }
}

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    @Transactional
    public void createUser(String username, String email) {
        User user = new User();
        user.setUsername(username);
        user.setEmail(email);
        userRepository.save(user);
    }
}

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String email;

    // Getters and setters
}

In this example:

• The SpringBootDemoApplication class is the main class of the Spring Boot application. It is annotated with @SpringBootApplication to enable auto-configuration and component scanning. Additionally, @EnableTransactionManagement is used to enable transaction management.
• The UserService class is a service component annotated with @Service. It contains a method createUser annotated with @Transactional. This annotation ensures that the method is executed within a transactional context.
• The User class is a JPA entity representing a user entity with basic fields like id, username, and email.
• The UserRepository interface extends JpaRepository to provide CRUD operations for the User entity.

With this setup, when the createUser method of the UserService is called, it will execute within a transactional context. If any exception occurs during the method execution, the transaction will be rolled back, ensuring data integrity and consistency.

How to handle Transactions for checked Exceptions ?

In Spring’s declarative transaction management, checked exceptions need to be explicitly configured to trigger a rollback. By default, only unchecked exceptions (RuntimeException and its subclasses) trigger a rollback. Here's how you can handle transactions for checked exceptions:

1. Using rollbackFor Attribute: You can specify the checked exceptions for which you want to trigger a rollback using the rollbackFor attribute of the @Transactional annotation. This attribute accepts an array of exception classes for which rollback should occur:

@Service
public class MyService {
    
    @Transactional(rollbackFor = {CustomCheckedException.class})
    public void myMethod() throws CustomCheckedException {
        // Business logic that may throw CustomCheckedException
    }
}

In this example, if CustomCheckedException is thrown during the execution of myMethod(), the transaction will be rolled back.

2. Using noRollbackFor Attribute: Conversely, you can specify exceptions for which you want to suppress rollback using the noRollbackFor attribute. Transactions will commit even if these exceptions occur:

@Service
public class MyService {
    
    @Transactional(noRollbackFor = {IOException.class})
    public void myMethod() throws IOException {
        // Business logic that may throw IOException
    }
}

In this example, if an IOException occurs during the execution of myMethod(), the transaction will commit without rolling back.

3. Using rollbackForClassName Attribute: You can also specify exceptions using their fully qualified class names instead of class literals. This approach is useful when the exception class is not available at compile time:

@Service
public class MyService {
    
    @Transactional(rollbackForClassName = {"com.example.CustomCheckedException"})
    public void myMethod() throws CustomCheckedException {
        // Business logic that may throw CustomCheckedException
    }
}

Ensure that the specified exception classes are correctly spelled and accessible in your application.

By configuring the appropriate rollbackFor or noRollbackFor attributes, you can control transaction behavior for both checked and unchecked exceptions in your Spring application. This provides flexibility in managing transactions based on the specific requirements of your business logic.

— — -Common Interview Questions — -

1. What happens if @Transactional is used on a private method?
Answer: It won’t work because Spring uses proxies to manage transactions, and proxies can only intercept calls to public methods.

2.How does @Transactional handle exceptions?

Answer:

• Rolls back for runtime exceptions (RuntimeException).
• To roll back for checked exceptions, use rollbackFor.

3. What is the default propagation type?
Answer: REQUIRED.

4. What is the difference between REQUIRED and REQUIRES_NEW propagation?

Answer:

• REQUIRED: Joins the current transaction.
• REQUIRES_NEW: Suspends the current transaction and starts a new one.

Scenario Example: In a banking system:

• REQUIRED: Deduct money and deposit in one transaction.
• REQUIRES_NEW: Send email notification in a separate transaction.

5. What is Rollback in @Transactional?

Answer: By default, Spring rolls back the transaction for runtime exceptions (RuntimeException). If you want to roll back for checked exceptions (e.g., SQLException), you can configure it using rollbackFor.

@Transactional(rollbackFor = SQLException.class)
public void updateDatabase() throws SQLException {
    // Database operations
    throw new SQLException("Database error occurred");
}

6. How does @Transactional work?

Answer: When a method annotated with @Transactional is called, Spring:

1. Starts a transaction.
2. Executes the method.
3. Commits the transaction if the method succeeds.
4. Rolls back the transaction if an exception occurs.

7. Why is @Transactional used?

Answer:It is used to:

• Ensure data consistency.
• Simplify transaction management in code.
• Reduce boilerplate code for transaction handling.

8.Can you use @Transactional on a class?

Answer:
Yes! When applied to a class, all public methods within the class become transactional.

9.Can a transaction timeout?

Answer:
Yes, you can set a timeout using the timeout attribute in @Transactional.

@Transactional(timeout = 10) // Rolls back if transaction takes more than 10 seconds
public void processOrder() {
    // Business logic
}

10. What is the default isolation level in Spring?

Answer:
The default isolation level is READ_COMMITTED, which prevents dirty reads but allows non-repeatable reads and phantom reads.

11. Can you use multiple transactions in one method?

Answer:
Yes, by using different propagation settings. For example, one operation can use REQUIRES_NEW while another uses REQUIRED.

12. What is the role of noRollbackFor?

Answer:
It specifies exceptions that should not trigger a rollback, even if they occur.

@Transactional(noRollbackFor = CustomException.class)
public void process() {
    throw new CustomException(); // Transaction won't roll back
}