Spring Events — tách luồng phụ khỏi luồng chính

TL;DR: ApplicationEventPublisher cho phép một service công bố "chuyện này đã xảy ra" thay vì tự gọi thẳng từng việc phụ như gửi mail hay ghi log. @EventListener mặc định chạy đồng bộ, cùng thread, cùng transaction với nơi publish: listener chậm thì method gốc chậm theo, listener throw thì kéo cả transaction rollback. Việc phụ có tác dụng phụ không thể thu hồi như gửi mail thì dùng @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) — chỉ chạy khi transaction đã commit. Event trong tiến trình không bền: crash giữa chừng là mất, không retry.

Sáu tháng trước, TaskService.assign() chỉ có năm dòng: tìm task, gán người, lưu. Bây giờ nó dài sáu mươi dòng — mỗi tính năng mới cần biết "task vừa được gán cho ai" (gửi mail, ghi audit log, cập nhật thống kê, bắn webhook) lại mở đúng method này ra sửa. Việc chính bị chôn giữa bốn việc phụ, review pull request giờ tốn nhiều thời gian đọc code không liên quan hơn đọc logic gán việc thật sự.

Bài này giải thích cách Spring Events tách việc phụ khỏi luồng chính, và điểm hay bị hiểu sai nhất: @EventListener không phải "bất đồng bộ theo mặc định" — nó chạy ngay lập tức, đồng bộ, trong cùng transaction.

1. Ý tưởng — công bố event thay vì gọi thẳng

Cách viết tự nhiên nhất khi thêm một việc phụ là mở method gốc ra, thêm một dòng gọi thẳng. Vấn đề là method gốc trở thành điểm hội tụ của mọi thứ — vừa phải biết cách gán task, vừa phải biết định dạng mail, định dạng audit log. Càng nhiều việc phụ, method càng phình, và mọi thay đổi ở một việc phụ đều có nguy cơ đụng vào phần gán task đang chạy ổn định.

Spring Events lật ngược quan hệ đó. Bên phát (TaskService) chỉ công bố "chuyện này đã xảy ra" qua ApplicationEventPublisher, không cần biết ai đang nghe. Bên nghe (@EventListener) tự đăng ký nhận đúng loại event mình quan tâm — đúng interface ApplicationEventPublisher đã xuất hiện lúc container khởi động ở khoá Spring Core (mọi ApplicationContext publish event vòng đời qua cơ chế này); ở đây bạn dùng lại nó cho event nghiệp vụ của riêng ứng dụng.

Event nên là một record bất biến, dùng lại pattern DTO đã quen ở module 01. Record mang đúng dữ liệu tại thời điểm xảy ra, không mang entity còn sống mà listener có thể sửa lung tung:

public record TaskAssignedEvent(
        Long taskId,
        Long assigneeId,
        Long assignedBy,
        Instant assignedAt) {
}

TaskService.assign() sau khi tách chỉ còn việc của nó: tìm task, gán, lưu, publish một event.

@Service
public class TaskService {

    private final TaskRepository taskRepo;
    private final ApplicationEventPublisher publisher;

    public TaskService(TaskRepository taskRepo, ApplicationEventPublisher publisher) {
        this.taskRepo = taskRepo;
        this.publisher = publisher;
    }

    @Transactional
    public Task assign(Long taskId, Long assigneeId) {
        Task task = taskRepo.findById(taskId).orElseThrow();
        task.setAssigneeId(assigneeId);
        taskRepo.save(task);

        publisher.publishEvent(new TaskAssignedEvent(
                taskId, assigneeId, currentUserId(), Instant.now()));

        return task;
    }
}

Bốn việc phụ giờ nằm ở bốn listener riêng, mỗi listener chỉ biết một việc:

@Component
public class AssignmentMailListener {

    private final MailSender mailSender;

    public AssignmentMailListener(MailSender mailSender) {
        this.mailSender = mailSender;
    }

    @EventListener
    public void onTaskAssigned(TaskAssignedEvent event) {
        mailSender.sendAssignedMail(event.assigneeId(), event.taskId());
    }
}

TaskService không còn biết MailSender tồn tại. Thêm việc phụ thứ năm là thêm một listener mới, không đụng assign().

flowchart TB
    subgraph before["Truoc: goi thang tu TaskService"]
        A1["assign()"] --> A2["send mail"]
        A1 --> A3["ghi audit log"]
        A1 --> A4["cap nhat thong ke"]
        A1 --> A5["ban webhook"]
    end
    subgraph after["Sau: publish, subscribe"]
        B1["assign() publish TaskAssignedEvent"] -.-> C1["MailListener"]
        B1 -.-> C2["AuditListener"]
        B1 -.-> C3["StatsListener"]
        B1 -.-> C4["WebhookListener"]
    end
    A5 -. "refactor: tach event" .-> B1

2. Vì sao @EventListener mặc định đồng bộ lại nguy hiểm?

Đây là chỗ hiểu nhầm phổ biến nhất về Spring Events: nhiều người đọc "event-driven" rồi mặc định nó chạy bất đồng bộ. Sự thật ngược lại — @EventListener mặc định chạy đồng bộ, trên đúng thread đang gọi publishEvent(), trong cùng transaction context nếu có transaction đang mở; publishEvent() block tới khi mọi listener chạy xong mới trả về.

Hệ quả trực tiếp: listener chậm thì assign() chậm theo — SMTP server phản hồi mất hai giây thì người dùng chờ đúng hai giây đó, dù họ không quan tâm mail đã gửi hay chưa. Hệ quả thứ hai nghiêm trọng hơn: listener ném exception thì exception lan ngược lên assign(), và vì method đang chạy trong @Transactional, toàn bộ transaction gốc rollback, kể cả phần lưu task hoàn toàn hợp lệ.

@Transactional
public Task assign(Long taskId, Long assigneeId) {
    Task task = taskRepo.findById(taskId).orElseThrow();
    task.setAssigneeId(assigneeId);
    taskRepo.save(task);

    publisher.publishEvent(new TaskAssignedEvent(
            taskId, assigneeId, currentUserId(), Instant.now()));
    // AssignmentMailListener chay NGAY tai day - dong bo, cung transaction
    // Mail da roi khoi SMTP server truoc khi dong ngoac nay ket thuc

    validateWorkload(assigneeId);   // vuot han muc thi throw -> ROLLBACK
    return task;
}

3. @TransactionalEventListener và AFTER_COMMIT

@TransactionalEventListener giải đúng vấn đề trên: thay vì chạy ngay khi publishEvent() được gọi, nó gắn việc thực thi vào một pha cụ thể của vòng đời transaction. Mặc định, và cũng là lựa chọn đúng cho gửi mail hay thông báo, là AFTER_COMMIT — listener chỉ chạy sau khi transaction gốc đã commit thành công.

// trong AssignmentMailListener
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onTaskAssigned(TaskAssignedEvent event) {
    mailSender.sendAssignedMail(event.assigneeId(), event.taskId());
}

Với thay đổi này, nếu validateWorkload() throw và transaction rollback, onTaskAssigned không bao giờ chạy — Spring chỉ gọi nó khi transaction đóng lại bằng commit thật sự. Mail "đã gán" giờ chỉ đi ra khi dữ liệu trong DB thật sự phản ánh đúng điều mail nói.

flowchart TB
    T0["assign bat dau - @Transactional"] --> T1["taskRepo.save(task)"]
    T1 --> T2["publisher.publishEvent(...)"]
    T2 --> T3["@EventListener chay NGAY - dong bo, cung transaction"]
    T3 --> T4{"code sau do co throw?"}
    T4 -- "co" --> T5["ROLLBACK - mail o T3 da gui roi"]
    T4 -- "khong" --> T6["COMMIT that su"]
    T6 --> T7["@TransactionalEventListener AFTER_COMMIT chay o day"]

TransactionPhase còn ba giá trị khác, ít dùng hơn nhưng nên biết:

Không có transaction nào đang chạy khi publishEvent() được gọi thì listener @TransactionalEventListener mặc định không chạy — muốn vẫn chạy, khai thêm fallbackExecution = true.

4. Bẫy — transaction đã đóng, muốn ghi tiếp phải mở transaction mới

Listener chạy ở AFTER_COMMIT đứng NGOÀI transaction gốc — transaction đó đã đóng, connection đã trả về pool. Nếu listener cần ghi thêm vào DB, chẳng hạn lưu "đã gửi mail lúc mấy giờ" để tránh gửi trùng, nó không thể dựa vào transaction cũ vì transaction đó không còn tồn tại.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void onTaskAssigned(TaskAssignedEvent event) {
    mailSender.sendAssignedMail(event.assigneeId(), event.taskId());
    mailLogRepo.save(new MailLog(event.taskId(), Instant.now()));
}

Propagation.REQUIRES_NEW, đã dạy kỹ ở khoá spring-rest-data, mở một transaction hoàn toàn mới, độc lập với transaction gốc đã đóng. Thiếu annotation này, mailLogRepo.save(...) chạy ngoài mọi transaction boundary tường minh — hành vi phụ thuộc open-in-view và các chi tiết ngầm định khác mà bạn không nên đặt cược vào. Thực tế hay gặp: chạy đúng lúc test tay (test case tự bọc transaction riêng), nhưng lên production thì âm thầm không có gì được flush xuống DB.

5. Kết hợp @Async với event

Listener AFTER_COMMIT vẫn chạy trên CÙNG thread đã gọi assign() — chỉ đổi THỜI ĐIỂM chạy, không đổi thread. Muốn assign() trả response ngay, kết hợp thêm @Async:

@Async
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onTaskAssigned(TaskAssignedEvent event) {
    mailSender.sendAssignedMail(event.assigneeId(), event.taskId());
}

Hai annotation trả lời hai câu hỏi khác nhau: @TransactionalEventListener quyết định CHẠY KHI NÀO (chỉ sau commit), @Async quyết định CHẠY TRÊN THREAD NÀO. Đừng nhầm sang dùng thẳng @EventListener thường cộng @Async: nó vẫn kích hoạt NGAY khi publishEvent() được gọi, giữa chừng transaction, còn chưa biết commit hay rollback — @Async chỉ đổi thread thực thi, không làm listener đợi commit. Thread mới có thể gửi mail xong trước khi transaction gốc kịp commit, quay lại đúng lỗi bài này mở đầu, chỉ khó phát hiện hơn vì chạy trên thread khác.

6. Ranh giới — event trong tiến trình không bền

Mọi thứ vừa học chạy trong CÙNG một tiến trình (in-process). Event không đi qua network, không lưu vào đâu cả — chỉ là một lời gọi method Spring định tuyến tới listener, trong bộ nhớ JVM đang chạy. Ứng dụng crash đúng lúc giữa "commit" và "listener AFTER_COMMIT chạy xong" thì event mất vĩnh viễn, không retry, không hàng đợi.

Với gửi mail hay ghi log thống kê, mất một lần trong một triệu lần restart là chấp nhận được. Nhưng nếu việc phụ đó quan trọng, ví dụ trừ tiền ví hay đồng bộ kế toán, mất một event là mất tiền thật. Bài toán đó cần outbox pattern: ghi event vào một bảng trong chính DB, CÙNG transaction với thay đổi nghiệp vụ, rồi một tiến trình riêng đọc bảng đó và phát ra message broker như Kafka. Khoá học này dừng ở việc bạn biết đường đi tiếp.

7. Tự thiết kế — ráp bốn quyết định vào một chữ ký

@Async
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void onTaskAssigned(TaskAssignedEvent event) {
    mailSender.sendAssignedMail(event.assigneeId(), event.taskId());
    assignmentLogRepo.save(new AssignmentLog(event.taskId(), Instant.now()));
}

Bốn quyết định dựa trên §3–§5: (1) chỉ @TransactionalEventListener hoãn thực thi tới đúng pha transaction, @EventListener luôn chạy ngay. (2) AFTER_COMMIT — task phải nằm trong DB trước khi gửi mail hay ghi log. (3) Có — @Async để assign() trả response ngay, chỉ đổi THREAD, không đổi thời điểm. (4) Có — transaction gốc đã đóng tại AFTER_COMMIT, thiếu REQUIRES_NEW thì log dễ âm thầm không được flush.

Pitfall thường gặp

❌ Biến event thành luồng nghiệp vụ chính: khi bước B bắt buộc phải xảy ra để bước A coi là thành công, quan hệ đó phải là lời gọi method trực tiếp, đọc được bằng cách lần theo code từ trên xuống. Event hợp cho việc phụ độc lập, fail riêng được — dùng cho luồng chính khiến lỗi khó lần theo, phải nhảy qua nhiều listener rải rác mới ráp lại được.

❌ Giả định thứ tự listener: nhiều listener cùng nghe một event không đảm bảo chạy theo thứ tự khai báo. Cần thứ tự cụ thể thì dùng @Order(1), @Order(2) tường minh, đừng dựa vào "test chạy đúng thứ tự nên production cũng vậy".

❌ Nuốt exception im lặng khi listener chạy @Async: method void throw exception, Spring chỉ log qua handler mặc định rồi tiếp tục như chưa có gì xảy ra. Cấu hình AsyncUncaughtExceptionHandler riêng (đã học ở bài @Async) để biết listener có đang âm thầm fail.

Đào sâu

Liên hệ các bài khác

• Bài 01 — Cache abstraction — cùng cơ chế AOP proxy đứng sau @EventListener lẫn @Cacheable, nhưng listener không dính bẫy self-call.
• Bài 03 — Async và executor — nguồn của hai vấn đề chính bài này: ThreadLocal không theo sang thread mới, exception bị nuốt khi @Async trả về void.
• Bài 06 — Mini-challenge TaskFlow v6 — áp cả năm khái niệm của module vào một tình huống thiết kế thật.

Tóm tắt

• Method bỗng chậm hoặc rollback sau khi thêm @EventListener? Nghi ngay nó — mặc định chạy đồng bộ, cùng thread và transaction, nên lỗi hay độ trễ đổ thẳng lên method gốc.
• Việc phụ có tác dụng phụ không thể thu hồi (mail, webhook)? Hỏi trước: annotation đang dùng có đợi transaction đóng lại, hay chỉ "nghe" đúng tên.
• Listener chạy AFTER_COMMIT đứng ngoài transaction gốc; cần ghi DB tiếp thì phải khai Propagation.REQUIRES_NEW tường minh, đừng dựa vào ngầm định.
• Ghép @Async sau @TransactionalEventListener, không phải thay cho nó — dùng riêng @EventListener cộng @Async đưa bạn về lại đúng lỗi rollback-nhưng-mail-đã-gửi.
• Trước khi dùng Spring Events cho một luồng: mất một event có làm mất tiền hay dữ liệu thật không? Có thì cần outbox pattern hoặc broker thật.

Tự kiểm tra

Bài tiếp theo: Mini-challenge — TaskFlow v6