Transaction Propagation, Isolation và Tối Ưu Hóa readOnly

TL;DR: propagation thiết lập ranh giới giao dịch: REQUIRED (mặc định) gộp chung vào transaction hiện tại (cùng commit/rollback), trong khi REQUIRES_NEW mở một transaction độc lập (thích hợp cho Audit Log). isolation kiểm soát khả năng nhìn thấy dữ liệu giữa các luồng đồng thời: READ_COMMITTED ngăn Dirty Read, REPEATABLE_READ ngăn Non-repeatable Read, và SERIALIZABLE ngăn Phantom Read. Cấu hình readOnly = true giúp Hibernate tắt Dirty Checking và tối ưu bộ nhớ heap.

Các chiến lược Propagation điều khiển ranh giới Transaction ra sao?

Khi Service A gọi Service B, thuộc tính propagation quyết định B sẽ tham gia vào transaction của A hay mở một transaction độc lập:

Cạm bẫy REQUIRED + try/catch gây UnexpectedRollbackException

Nhiều lập trình viên lầm tưởng việc bọc try-catch quanh lời gọi method con sẽ giúp method cha commit bình thường nếu method con thất bại:

// SAI LAM NGHIEP VU:
@Transactional // T1
public Order placeOrder(OrderRequest req) {
    Order order = orderRepo.save(new Order(req));
    try {
        inventoryService.reserve(req.items()); // REQUIRED: Join T1 va nem loi
    } catch (Exception e) {
        log.warn("Giu kho that bai nhung van muon luu don hang");
    }
    return order; // NEM UnexpectedRollbackException TAI DAY!
}

Cơ chế bên dưới: Khi reserve() ném runtime exception, Spring Transaction Interceptor lập tức đánh dấu cờ rollback-only lên T1 ngay tại thời điểm xảy ra ngoại lệ. Cho dù method cha có catch lỗi, khi kết thúc method và Spring cố phát lệnh COMMIT, nó phát hiện cờ rollback-only và ném ngoại lệ UnexpectedRollbackException.

Khắc phục: Nếu muốn reserve() thất bại mà không ảnh hưởng tới placeOrder(), bắt buộc phải chuyển sang REQUIRES_NEW.

Các cấp độ Isolation ngăn chặn những bất thường nào?

Isolation kiểm soát mức độ cô lập giữa các transaction chạy song song:

(PostgreSQL triển khai REPEATABLE_READ qua MVCC nên trên thực tế ngăn chặn được cả Phantom Read).

// Ap dung cho nghiep vu chuyen tien doi hoi tinh nhat quan cao
@Transactional(isolation = Isolation.REPEATABLE_READ)
public void transferMoney(Long fromId, Long toId, BigDecimal amount) { ... }

Cơ chế bên dưới của thuộc tính readOnly = true là gì?

Khi khai báo @Transactional(readOnly = true), hệ thống kích hoạt 3 cơ chế tối ưu hóa:

1. Hibernate tắt Dirty Checking: Bỏ qua bước tạo bản sao snapshot trong bộ nhớ, tiết kiệm tới ~30% dung lượng RAM heap per entity.
2. Thiết lập FlushMode.MANUAL: Ngăn chặn Hibernate tự động phát lệnh flush trước mỗi câu truy vấn.
3. Gửi tín hiệu tới JDBC Driver: Đặt connection.setReadOnly(true), cho phép các proxy như PgBouncer tự động điều hướng kết nối tới database Read-Replica.

Cạm bẫy sửa dữ liệu trong readOnly Transaction

Nếu bạn vô tình gọi setter cập nhật entity trong một phương thức readOnly = true:

@Transactional(readOnly = true)
public void updateStatus(Long id) {
    Order order = repo.findById(id).orElseThrow();
    order.setStatus(PAID); // HIBERNATE BO QUA, KHONG FLUSH UPDATE XUONG DB!
}

Mã nguồn vẫn chạy trơn tru, không có bất kỳ exception nào ném ra, nhưng dữ liệu hoàn toàn không được cập nhật xuống cơ sở dữ liệu (Silent No-Op).

Những cạm bẫy phổ biến cần tránh là gì?

1. Dùng REQUIRES_NEW trong vòng lặp lớn: Mỗi lần gọi REQUIRES_NEW đều tốn tài nguyên xin kết nối mới từ connection pool, dễ gây cạn kiệt pool và làm chậm hệ thống.
2. Lạm dụng Isolation SERIALIZABLE: Gây nghẽn cổ chai hiệu năng và phát sinh lỗi tranh chấp transaction liên tục.
3. Quên ghi đè @Transactional ở tầng method: Khi Service class được đánh dấu @Transactional(readOnly = true), các method ghi (CUD) quên khai báo @Transactional riêng sẽ không thể lưu dữ liệu.

Tự kiểm tra kiến thức

Bài tiếp theo: Tổng Kết Module 06: Relationships & Transactions