Làm chủ giao dịch trong Spring: Cam kết, Hoàn tác, Lặp lại

Xin chào các bạn trên hành trình khám phá “Java Spring Roadmap”!

Sau khi cùng nhau đi qua những khái niệm cốt lõi như IoC, Dependency Injection, AOP, cách cấu hình, và thậm chí là xây dựng ứng dụng web đầu tiên với Spring MVC hay hiểu về Spring Boot, chúng ta đã có một nền tảng vững chắc. Nếu bạn chưa theo dõi, hãy bắt đầu từ Spring Boot Roadmap – Lộ trình phát triển cho Java Spring Boot 2025 hoặc tìm hiểu Tại sao chọn Spring? và các bài viết về Thuật Ngữ Cốt Lõi, Kiến Trúc Cốt Lõi, hay Dependency Injection.

Hôm nay, chúng ta sẽ lặn sâu vào một chủ đề cực kỳ quan trọng trong phát triển ứng dụng doanh nghiệp: Quản lý Transaction (Giao dịch). Đặc biệt là làm chủ cách Spring giúp chúng ta xử lý các thao tác Commit, Rollback một cách hiệu quả và đáng tin cậy.

Tại Sao Transaction Lại Quan Trọng Đến Thế?

Hãy tưởng tượng bạn đang xây dựng một hệ thống ngân hàng. Một thao tác đơn giản như “Chuyển tiền từ tài khoản A sang tài khoản B” thực chất bao gồm nhiều bước:

1. Kiểm tra số dư tài khoản A.
2. Trừ tiền từ tài khoản A.
3. Cộng tiền vào tài khoản B.
4. Ghi lại lịch sử giao dịch.

Điều gì xảy ra nếu sau khi trừ tiền từ tài khoản A, hệ thống gặp lỗi (mất mạng, sập server, lỗi code…) trước khi kịp cộng tiền vào tài khoản B? Tài khoản A bị trừ tiền, nhưng tài khoản B không nhận được tiền! Dữ liệu của bạn trở nên không nhất quán, gây ra hậu quả nghiêm trọng.

Đây chính là lúc Transaction tỏa sáng. Một Transaction là một đơn vị công việc logic duy nhất, bao gồm một hoặc nhiều thao tác. Nguyên tắc cơ bản là:

• Tất cả thành công: Nếu tất cả các thao tác trong Transaction đều hoàn thành mà không có lỗi, toàn bộ thay đổi sẽ được lưu vào cơ sở dữ liệu (Commit).
• Tất cả thất bại: Nếu bất kỳ thao tác nào trong Transaction gặp lỗi, tất cả các thay đổi đã thực hiện trong Transaction đó sẽ bị hủy bỏ, đưa hệ thống về trạng thái trước khi Transaction bắt đầu (Rollback).

Thuộc tính cốt lõi của Transaction thường được gọi là ACID:

• Atomicity (Tính nguyên tử): Một transaction là một đơn vị không thể chia nhỏ. Hoặc toàn bộ thành công, hoặc toàn bộ thất bại.
• Consistency (Tính nhất quán): Một transaction đưa cơ sở dữ liệu từ trạng thái hợp lệ này sang trạng thái hợp lệ khác.
• Isolation (Tính cô lập): Các transaction đang chạy đồng thời không ảnh hưởng lẫn nhau. Thay đổi của một transaction chỉ hiển thị với các transaction khác sau khi nó được commit.
• Durability (Tính bền vững): Một khi transaction đã được commit, thay đổi của nó là vĩnh viễn và sẽ tồn tại ngay cả khi hệ thống gặp sự cố.

Trong các ứng dụng Java hiện đại, đặc biệt là khi làm việc với cơ sở dữ liệu thông qua các framework ORM như Hibernate (mà chúng ta đã đề cập trong bài Hibernate Basics với Spring Boot), việc quản lý Transaction đúng cách là cực kỳ quan trọng để đảm bảo tính toàn vẹn dữ liệu.

Spring’s Transaction Management: Đơn Giản Hóa Sự Phức Tạp

Quản lý Transaction một cách thủ công (programmatic) trong JDBC hoặc các ORM đời cũ có thể rất cồng kềnh, yêu cầu viết nhiều khối try-catch-finally để xử lý commit/rollback. Spring làm cho việc này trở nên dễ dàng hơn rất nhiều thông qua abstraction và hỗ trợ cả hai cách tiếp cận:

• Programmatic Transaction Management: Bạn tự viết code để bắt đầu, commit, hoặc rollback transaction. Ít phổ biến hơn vì nó làm code nghiệp vụ bị trộn lẫn với logic quản lý transaction.
• Declarative Transaction Management: Bạn chỉ cần “khai báo” (thường bằng annotation) rằng một phương thức hoặc lớp cần chạy trong một transaction. Spring sẽ tự động xử lý việc bắt đầu, commit, và rollback transaction dựa trên cấu hình và kết quả thực thi của phương thức đó. Đây là cách được khuyến khích và sử dụng rộng rãi nhất trong Spring.

Điểm mạnh của Spring là nó cung cấp một lớp trừu tượng (abstraction layer) cho Transaction Management, độc lập với công nghệ nền tảng (JDBC, JPA/Hibernate, JTA…). Bạn viết code quản lý transaction một lần với Spring API, và Spring sẽ “phiên dịch” nó sang API cụ thể của công nghệ bạn đang dùng.

Bạn có thể thấy sự quen thuộc ở đây phải không? Đây lại là một ví dụ điển hình về cách Spring sử dụng Aspect-Oriented Programming (AOP) và Annotations để thêm các hành vi (như quản lý transaction) vào code của bạn mà không làm thay đổi logic nghiệp vụ chính. Khi bạn đánh dấu một phương thức bằng @Transactional, Spring sẽ tạo ra một Proxy (sử dụng AOP) bao quanh phương thức đó. Proxy này sẽ chứa logic để bắt đầu transaction trước khi gọi phương thức gốc và xử lý commit/rollback sau khi phương thức gốc hoàn thành hoặc ném ngoại lệ.

@Transactional: Chú Giải Phép Thuật Của Bạn

Annotation @Transactional là trái tim của Declarative Transaction Management trong Spring. Bạn có thể đặt nó ở cấp độ lớp hoặc cấp độ phương thức.

• Khi đặt ở cấp độ lớp, tất cả các phương thức public trong lớp đó sẽ kế thừa cấu hình transaction mặc định.
• Khi đặt ở cấp độ phương thức, nó sẽ ghi đè cấu hình ở cấp độ lớp (nếu có) cho phương thức cụ thể đó.

Ví dụ đơn giản nhất:

@Service
public class AccountService {

    @Autowired
    private AccountRepository accountRepository;

    @Autowired
    private TransactionLogRepository transactionLogRepository;

    

    @Transactional // Khai báo phương thức này cần chạy trong transaction
    public void transfer(Long fromAccountId, Long toAccountId, double amount) {
        // Bước 1: Lấy tài khoản
        Account fromAccount = accountRepository.findById(fromAccountId).orElseThrow(...);
        Account toAccount = accountRepository.findById(toAccountId).orElseThrow(...);

        // Bước 2: Kiểm tra số dư
        if (fromAccount.getBalance() < amount) {
            throw new InsufficientFundsException("Số dư không đủ");
        }

        // Bước 3: Trừ tiền và cộng tiền
        fromAccount.setBalance(fromAccount.getBalance() - amount);
        toAccount.setBalance(toAccount.getBalance() + amount);

        // Bước 4: Lưu thay đổi
        accountRepository.save(fromAccount);
        accountRepository.save(toAccount); // Nếu lỗi xảy ra ở đây, bước 3 sẽ bị rollback

        // Bước 5: Ghi log giao dịch
        TransactionLog log = new TransactionLog(fromAccountId, toAccountId, amount);
        transactionLogRepository.save(log); // Nếu lỗi ở đây, tất cả các bước trên cũng bị rollback

        // Nếu mọi thứ suôn sẻ, Spring sẽ tự động commit transaction khi phương thức kết thúc thành công.
        // Nếu có ngoại lệ (runtime exception hoặc error) xảy ra, Spring sẽ tự động rollback transaction.
    }
}

Trong ví dụ trên, nếu bất kỳ dòng code nào trong phương thức transfer ném ra một ngoại lệ Runtime (ví dụ: do mất kết nối DB, lỗi logic...), Spring sẽ bắt ngoại lệ đó và tự động Rollback toàn bộ Transaction. Nếu phương thức hoàn thành mà không có ngoại lệ Runtime, Spring sẽ tự động Commit Transaction, đảm bảo cả việc trừ tiền, cộng tiền và ghi log đều thành công hoặc không có gì xảy ra.

Đi Sâu Hơn: Transaction Propagation (Cách Các Transaction Tương Tác)

Đây là một khía cạnh quan trọng và đôi khi gây nhầm lẫn của Transaction Management. Propagation level (Mức độ lan truyền) quyết định cách một phương thức transactional sẽ hoạt động khi nó được gọi từ một ngữ cảnh đã có transaction hoặc chưa có transaction.

Spring định nghĩa nhiều propagation level khác nhau trong enum org.springframework.transaction.annotation.Propagation. Các mức phổ biến nhất là:

REQUIRED (Mặc định)

• Nếu phương thức được gọi trong một transaction hiện có, nó sẽ sử dụng transaction đó.
• Nếu phương thức được gọi mà không có transaction nào, Spring sẽ tạo một transaction mới.
• Đây là mức an toàn và phổ biến nhất cho hầu hết các hoạt động nghiệp vụ.

REQUIRES_NEW

• Luôn luôn tạo một transaction mới cho phương thức này.
• Nếu phương thức được gọi trong một transaction hiện có, transaction hiện tại sẽ bị tạm dừng cho đến khi transaction mới hoàn thành.
• Hữu ích khi bạn muốn một thao tác (ví dụ: ghi log lỗi vào database) luôn được commit thành công, ngay cả khi transaction chính bị rollback.

SUPPORTS

• Nếu có transaction hiện tại, sử dụng transaction đó.
• Nếu không có transaction hiện tại, phương thức sẽ chạy mà không có transaction nào.
• Thường dùng cho các phương thức chỉ đọc (read-only) không làm thay đổi dữ liệu.

NOT_SUPPORTED

• Chạy mà không có transaction nào.
• Nếu có transaction hiện tại, nó sẽ bị tạm dừng cho đến khi phương thức này kết thúc.

Còn các mức ít phổ biến hơn như MANDATORY (phải có transaction, nếu không ném ngoại lệ), NEVER (không được có transaction, nếu có ném ngoại lệ), và NESTED (chạy trong một sub-transaction, sử dụng savepoint).

Dưới đây là bảng tóm tắt các mức độ lan truyền Transaction phổ biến:

Lựa chọn propagation level phù hợp là rất quan trọng để kiểm soát luồng transaction trong ứng dụng của bạn.

Isolation Levels: Ranh Giới Của Dữ Liệu

Isolation Level (Mức độ cô lập) quyết định mức độ các transaction đang chạy đồng thời có thể nhìn thấy các thay đổi của nhau. Mức độ cô lập cao hơn giúp ngăn chặn các vấn đề về đọc dữ liệu không nhất quán nhưng có thể làm giảm hiệu suất do khóa (locking) dữ liệu nhiều hơn.

Các vấn đề phổ biến mà Isolation Level giúp ngăn chặn:

• Dirty Reads (Đọc dữ liệu "bẩn"): Một transaction đọc dữ liệu chưa được commit bởi một transaction khác. Nếu transaction thứ hai rollback, dữ liệu mà transaction thứ nhất đã đọc là không tồn tại.
• Non-Repeatable Reads (Đọc không lặp lại): Một transaction đọc cùng một hàng hai lần và nhận được các giá trị khác nhau, vì một transaction khác đã commit thay đổi cho hàng đó ở giữa hai lần đọc.
• Phantom Reads (Đọc "ma"): Một transaction chạy một query (ví dụ: COUNT hoặc SELECT where clause) hai lần và nhận được số lượng hàng khác nhau, vì một transaction khác đã insert hoặc delete các hàng phù hợp với query đó ở giữa hai lần chạy.

Các Isolation Level được định nghĩa trong enum org.springframework.transaction.annotation.Isolation (hoặc trong API JDBC/JPA), từ thấp đến cao:

• READ_UNCOMMITTED: Cho phép Dirty Reads, Non-Repeatable Reads, Phantom Reads. (Mức thấp nhất, ít locking nhất, nhanh nhất).
• READ_COMMITTED: Ngăn chặn Dirty Reads. Vẫn cho phép Non-Repeatable Reads, Phantom Reads. (Phổ biến ở nhiều DB như SQL Server, Oracle).
• REPEATABLE_READ: Ngăn chặn Dirty Reads, Non-Repeatable Reads. Vẫn cho phép Phantom Reads. (Phổ biến ở MySQL).
• SERIALIZABLE: Ngăn chặn tất cả các vấn đề trên. Các transaction được thực hiện như thể chúng chạy tuần tự. (Mức cao nhất, nhiều locking nhất, chậm nhất).

Bạn có thể chỉ định Isolation Level cho một transaction bằng thuộc tính isolation của @Transactional:

@Transactional(isolation = Isolation.READ_COMMITTED)
public Account getAccountBalance(Long accountId) {
    // Logic đọc số dư tài khoản
    return accountRepository.findById(accountId).orElse(null);
}

Nếu không chỉ định, Spring sẽ sử dụng Isolation Level mặc định của cơ sở dữ liệu hoặc cấu hình của PlatformTransactionManager.

Việc lựa chọn Isolation Level là sự đánh đổi giữa tính toàn vẹn dữ liệu và hiệu suất. Hầu hết các ứng dụng sử dụng mức mặc định của cơ sở dữ liệu (thường là READ_COMMITTED hoặc REPEATABLE_READ) và chỉ nâng lên SERIALIZABLE ở những nơi cực kỳ nhạy cảm về tính nhất quán dữ liệu, nơi mà các vấn đề đọc dữ liệu không nhất quán là không thể chấp nhận được.

Kiểm Soát Outcome: Commit và Rollback

Như đã đề cập, Spring sẽ tự động Commit transaction khi phương thức @Transactional hoàn thành mà không có ngoại lệ. Nó sẽ tự động Rollback transaction nếu một ngoại lệ Runtime (unchecked exception - extends RuntimeException) hoặc một Error được ném ra.

Rollback Mặc Định:

@Transactional
public void saveData(Data data) {
    dataRepository.save(data);
    if (somethingGoesWrongAtRuntime) {
        throw new RuntimeException("Lỗi nghiệp vụ không mong muốn"); // -> ROLLBACK
    }
    // Nếu đến đây mà không có lỗi, sẽ COMMIT
}

Kiểm Soát Rollback: rollbackFor và noRollbackFor

Bạn có thể tùy chỉnh hành vi rollback bằng cách sử dụng các thuộc tính rollbackFor và noRollbackFor của @Transactional:

• rollbackFor: Một mảng các lớp ngoại lệ. Spring sẽ thực hiện rollback nếu ngoại lệ được ném ra là một trong các lớp này (hoặc lớp con của chúng), ngay cả khi chúng là checked exception.
• noRollbackFor: Một mảng các lớp ngoại lệ. Spring sẽ *không* thực hiện rollback nếu ngoại lệ được ném ra là một trong các lớp này (hoặc lớp con của chúng).

Ví dụ:

// Rollback khi gặp cả RuntimeException và CustomCheckedException
@Transactional(rollbackFor = {RuntimeException.class, CustomCheckedException.class})
public void processOrder(Order order) throws CustomCheckedException {
    // ... xử lý đơn hàng ...
    if (paymentFailed) {
        throw new CustomCheckedException("Thanh toán thất bại, cần rollback"); // -> ROLLBACK
    }
    // ...
}

// KHÔNG rollback khi gặp IgnoreableBusinessException (dù là RuntimeException)
@Transactional(noRollbackFor = IgnoreableBusinessException.class)
public void processLog(LogEntry entry) {
    // ... xử lý log ...
    if (minorErrorOccurred) {
        throw new IgnoreableBusinessException("Lỗi nhỏ, không cần rollback"); // -> COMMIT
    }
    // ...
}

Điều này rất hữu ích khi bạn có các ngoại lệ checked exception đại diện cho lỗi nghiệp vụ mà bạn muốn kích hoạt rollback, hoặc các ngoại lệ runtime exception mà bạn không muốn nó gây rollback.

Programmatic Transaction (Nâng Cao/Trường Hợp Đặc Biệt)

Mặc dù Declarative (sử dụng @Transactional) là phổ biến và khuyến khích, có những trường hợp bạn có thể cần Programmatic Transaction Management. Ví dụ: khi logic transaction cần phức tạp hơn, hoặc khi bạn cần quản lý transaction động dựa trên điều kiện runtime.

Spring cung cấp PlatformTransactionManager và TransactionTemplate cho mục đích này. Bạn inject PlatformTransactionManager và sử dụng API của nó, hoặc tiện lợi hơn là sử dụng TransactionTemplate.

@Service
public class ReportService {

    @Autowired
    private TransactionTemplate transactionTemplate;

    @Autowired
    private ReportRepository reportRepository;

    

    public void generateComplexReport() {
        transactionTemplate.execute(status -> {
            try {
                // Logic phức tạp cần chạy trong transaction
                // Bao gồm nhiều bước đọc/ghi
                ReportData data = fetchAndProcessData();
                reportRepository.save(data);

                // Nếu có điều kiện gì đó, bạn có thể gọi rollback thủ công
                // status.setRollbackOnly();

                return null; // Return result if needed, or null for void

            } catch (Exception e) {
                // Xử lý ngoại lệ và đánh dấu rollback
                status.setRollbackOnly();
                throw new RuntimeException("Lỗi khi tạo báo cáo", e); // Ném lại ngoại lệ
            }
        });
    }
}

Cách này yêu cầu viết code nhiều hơn nhưng mang lại sự kiểm soát chi tiết. Tuy nhiên, hãy cố gắng sử dụng @Transactional bất cứ khi nào có thể để giữ cho code của bạn sạch sẽ và dễ bảo trì hơn.

Những Điều Cần Lưu Ý và Best Practices

Để làm chủ Transaction trong Spring, hãy ghi nhớ một số điểm quan trọng:

• Vấn đề Self-Invocation (Tự gọi): Khi một phương thức @Transactional trong một bean Spring gọi một phương thức @Transactional *khác* trong *chính bean đó* (sử dụng this.method()), transaction sẽ không hoạt động như mong đợi cho phương thức được gọi. Điều này xảy ra vì AOP proxy mà Spring tạo ra chỉ chặn các cuộc gọi *từ bên ngoài* bean. Cuộc gọi nội bộ bỏ qua proxy. Giải pháp: Gọi phương thức thông qua một bean khác, hoặc inject chính bean đó vào một field và gọi qua field đó (cần cấu hình proxy mode).
• Giữ Transaction Methods Ngắn Gọn: Các phương thức @Transactional nên chỉ chứa logic nghiệp vụ liên quan đến việc truy cập và thay đổi dữ liệu. Tránh đặt các thao tác tốn thời gian không liên quan đến DB (gửi email, gọi external API...) vào trong transaction, vì nó sẽ giữ kết nối DB và khóa tài nguyên không cần thiết.
• Xử Lý Ngoại Lệ Cẩn Thận: Đừng bắt và "nuốt" các ngoại lệ Runtime *bên trong* một phương thức @Transactional nếu bạn muốn nó kích hoạt rollback. Hãy để ngoại lệ được ném ra ngoài để Spring proxy có thể bắt và xử lý rollback.
• Sử Dụng readOnly = true cho Read Operations: Đối với các phương thức chỉ đọc dữ liệu và không thay đổi gì, hãy đặt @Transactional(readOnly = true). Spring và các ORM có thể áp dụng các tối ưu hóa (ví dụ: không đánh dấu các đối tượng entity là "dirty", sử dụng session chỉ đọc) giúp cải thiện hiệu suất. Nó cũng gợi ý cho người đọc code biết mục đích của phương thức.

    @Transactional(readOnly = true)
    public List<Product> getAllProducts() {
        return productRepository.findAll();
    }
    

Kết Luận

Transaction Management là một kỹ năng không thể thiếu đối với bất kỳ developer nào làm việc với ứng dụng đòi hỏi tính toàn vẹn dữ liệu cao. Spring, với sự hỗ trợ mạnh mẽ cho Declarative Transaction Management thông qua @Transactional, đã đơn giản hóa đáng kể việc quản lý các kịch bản Commit, Rollback phức tạp.

Việc nắm vững các khái niệm về Propagation, Isolation, và cách kiểm soát Rollback sẽ giúp bạn xây dựng các ứng dụng robust, đáng tin cậy, và dễ bảo trì hơn. Hãy thực hành thật nhiều với @Transactional trong các dự án của bạn.

Hành trình Java Spring Roadmap của chúng ta vẫn còn tiếp diễn. Tiếp theo, chúng ta sẽ cùng nhau khám phá những khía cạnh thú vị khác của Spring, có thể là về Data Access nâng cao hoặc các chủ đề khác đã được gợi ý trong lộ trình tổng thể.

Hãy tiếp tục học hỏi và thực hành nhé! Hẹn gặp lại các bạn ở bài viết tiếp theo.