Transaction_And_Concurrency

1. Transaction Isolation Levels

Trong Spring Data JPA, chúng ta có thể kiểm soát mức độ cách ly của các giao dịch bằng cách sử dụng các Transaction Isolation Levels.

🔹 Các Mức Cách Ly trong Transaction

Isolation Level
Dirty Read
Non-repeatable Read
Phantom Read

READ UNCOMMITTED

✅ Có

✅ Có

✅ Có

READ COMMITTED

❌ Không

✅ Có

✅ Có

REPEATABLE READ

❌ Không

❌ Không

✅ Có

SERIALIZABLE

❌ Không

❌ Không

❌ Không

🔹 Vấn Đề Cần Giải Quyết

  1. Dirty Read 🟠

    • Một transaction có thể đọc dữ liệu chưa commit từ transaction khác.

    • Có thể dẫn đến trạng thái không nhất quán khi transaction bị rollback.

    • Giải pháp: READ COMMITTED trở lên.

  2. Non-repeatable Read 🟡

    • Một transaction đọc cùng một bản ghi nhiều lần nhưng nhận được các giá trị khác nhau do transaction khác đã thay đổi dữ liệu.

    • Giải pháp: REPEATABLE READ trở lên.

  3. Phantom Read 🔴

    • Một transaction thực hiện cùng một truy vấn nhiều lần nhưng nhận được tập kết quả khác nhau do transaction khác đã thêm/xóa dữ liệu.

    • Giải pháp: SERIALIZABLE.

🔹 Cấu hình Isolation Level trong Spring Boot

Spring Data JPA hỗ trợ việc thiết lập mức cách ly bằng @Transactional(isolation = Isolation.LEVEL).

Ví dụ: Chỉ đọc dữ liệu đã được commit (READ COMMITTED):

@Transactional(isolation = Isolation.READ_COMMITTED)
public void processOrder(Long orderId) {
    // Code xử lý đơn hàng
}

2. Pessimistic vs Optimistic Locking

Locking giúp tránh xung đột dữ liệu trong các ứng dụng nhiều luồng.

🔹 Optimistic Locking (Khóa Lạc Quan)

  • Sử dụng @Version để kiểm soát xung đột mà không cần khóa cấp database.

  • Nếu dữ liệu bị sửa đổi bởi transaction khác, JPA sẽ ném ngoại lệ (OptimisticLockException).

  • Ưu điểm: Không khóa dữ liệu, hiệu suất tốt hơn.

  • Nhược điểm: Nếu có nhiều cập nhật đồng thời, có thể gây lỗi lặp.

🔹 Cách triển khai Optimistic Locking với @Version

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private Double price;

    @Version
    private Integer version; // Dùng để kiểm soát xung đột
}

  • Khi một bản ghi được đọc, version sẽ được lưu lại.

  • Khi cập nhật bản ghi, JPA kiểm tra xem version có thay đổi không.

  • Nếu có thay đổi từ transaction khác, JPA sẽ ném ngoại lệ.

🔹 Cách xử lý ngoại lệ Optimistic Locking

try {
    productService.updateProductPrice(productId, newPrice);
} catch (OptimisticLockException e) {
    // Xử lý khi có xung đột cập nhật
    System.out.println("Conflict detected, retrying...");
}

🔹 Pessimistic Locking (Khóa Bi Quan)

  • Dùng khi dữ liệu được đọc và ghi thường xuyên.

  • Có 2 loại khóa chính:

    • PESSIMISTIC_READ: Chặn ghi nhưng vẫn cho phép đọc.

    • PESSIMISTIC_WRITE: Chặn cả đọc và ghi từ các transaction khác.

🔹 Cách dùng Pessimistic Locking trong Spring Data JPA

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Product p WHERE p.id = :id")
Optional<Product> findByIdForUpdate(@Param("id") Long id);

  • Khi một transaction lấy dữ liệu, nó sẽ chặn các transaction khác đọc và ghi vào bản ghi đó.

🔹 Khi nào nên dùng? ✅ Optimistic Locking → Khi xung đột hiếm xảy ra. ✅ Pessimistic Locking → Khi có nhiều cập nhật đồng thời vào cùng dữ liệu.

3. Deadlock & Database Locking Strategies

🔹 Deadlock là gì?

  • Deadlock xảy ra khi hai transaction chờ nhau để giải phóng khóa và không thể tiếp tục.

  • VD:

    • Transaction A khóa Bản ghi 1, cần Bản ghi 2.

    • Transaction B khóa Bản ghi 2, cần Bản ghi 1.

    • Cả hai bị kẹt 🛑.

🔹 Cách tránh Deadlock

  1. Duy trì thứ tự truy cập dữ liệu

    • Luôn truy vấn dữ liệu theo cùng một thứ tự để tránh deadlock.

  2. Giới hạn thời gian khóa

    • Dùng lock timeout để tránh chờ vô hạn:

  • @Transactional(timeout = 5)Sử dụng Retry Mechanism

  • Khi bị deadlock, thử lại giao dịch sau vài mili giây.

Advisory Locks trong PostgreSQL

  • Advisory Lock là một dạng khóa mà ứng dụng tự quản lý thay vì database tự động khóa bản ghi.

  • Dùng khi cần kiểm soát truy cập mà không cần khóa row-level.

SELECT pg_advisory_lock(12345);  -- Giữ khóa
SELECT pg_advisory_unlock(12345); -- Bỏ khóa

Sử dụng cho các tác vụ mà không muốn JPA tự động khóa dữ liệu.

🚀 Tổng Kết

Tính năng
Khi nào dùng?

READ COMMITTED

Ngăn dirty read nhưng cho phép non-repeatable read

REPEATABLE READ

Ngăn dirty read và non-repeatable read nhưng có phantom read

SERIALIZABLE

Chặn mọi xung đột nhưng có thể gây chậm

Optimistic Locking (@Version)

Khi xung đột hiếm, ít ảnh hưởng hiệu suất

Pessimistic Locking (@Lock)

Khi có nhiều transaction ghi đồng thời

Advisory Locks

Khi muốn kiểm soát thủ công mà không khóa database

PreviousSpringDataJPA_ArchitechtureNextEntity_LifeCycle

Last updated