Trong hệ thống đa luồng (Multi-threading) hoặc đa tiến trình (Multi-process) truy cập cùng một cơ sở dữ liệu SQLite, lỗi SQLITE_BUSY thường xuất hiện do đâu? Hãy giải thích chi tiết các trạng thái Locking trong SQLite và đề xuất giải pháp xử lý triệt để lỗi này ở cấp độ hệ thống Enterprise.

Question

Accepted Answer

1. Nguyên nhân gây ra lỗi SQLITE_BUSY
Lỗi SQLITE_BUSY xuất hiện khi một tiến trình hoặc luồng cố gắng ghi hoặc đọc dữ liệu từ tệp cơ sở dữ liệu SQLite nhưng tệp đó đang bị khóa bởi một tiến trình/luồng khác. SQLite áp dụng cơ chế khóa ở cấp độ tệp (File-level Locking) hoặc cấp độ trang (Database Page Locking), dẫn đến xung đột khi có nhiều thao tác ghi đồng thời.
2. Các trạng thái Locking (Locking States) trong SQLite
Ở chế độ Rollback Journal truyền thống, SQLite quản lý truy cập đồng thời thông qua 5 trạng thái khóa theo thứ tự tăng dần:

UNLOCKED: Cơ sở dữ liệu chưa được truy cập.
SHARED: Cho phép nhiều tiến trình đọc dữ liệu đồng thời. Không tiến trình nào được ghi khi có ít nhất một SHARED lock.
RESERVED: Một tiến trình dự định ghi dữ liệu trong tương lai. Chỉ duy nhất một RESERVED lock được tồn tại tại một thời điểm, nhưng các tiến trình khác vẫn có thể tiếp tục đọc (SHARED lock).
PENDING: Tiến trình chuẩn bị nâng cấp lên EXCLUSIVE lock để ghi dữ liệu. Ở trạng thái này, không SHARED lock mới nào được cấp phát thêm, tiến trình chờ các SHARED lock hiện tại giải phóng hết.
EXCLUSIVE: Tiến trình có quyền ghi hoàn toàn vào tệp cơ sở dữ liệu. Không tiến trình nào khác được đọc hoặc ghi.

Lỗi SQLITE_BUSY xảy ra khi một luồng cố gắng nâng cấp từ SHARED sang RESERVED/EXCLUSIVE nhưng gặp phải xung đột khóa với một luồng khác mà không thể chờ thêm.
3. Giải pháp cấp độ Enterprise để xử lý triệt để
a. Cấu hình Busy Timeout và Busy Handler
Thiết lập khoảng thời gian chờ (timeout) để SQLite tự động thử lại (retry) trước khi ném ra lỗi SQLITE_BUSY:
PRAGMA busy_timeout = 5000; -- Cho phép chờ tối đa 5000ms (5 giây)
Hoặc đăng ký một custom sqlite3_busy_handler trong code ứng dụng với chiến lược Exponential Backoff.
b. Sử dụng Immediate Transactions cho các thao tác Ghi
Mặc định, giao dịch trong SQLite là DEFERRED (chỉ xin khóa SHARED khi bắt đầu, và chỉ xin khóa RESERVED khi thực hiện câu lệnh INSERT/UPDATE/DELETE đầu tiên). Điều này dễ gây ra Deadlock khi hai luồng cùng bắt đầu DEFERRED transaction và cùng muốn ghi.
Giải pháp: Khởi tạo giao dịch ghi bằng BEGIN IMMEDIATE hoặc BEGIN EXCLUSIVE ngay từ đầu:
BEGIN IMMEDIATE TRANSACTION;
-- Thực hiện các lệnh UPDATE/INSERT tại đây
COMMIT;
BEGIN IMMEDIATE sẽ xin khóa RESERVED ngay lập tức. Nếu một luồng khác đang giữ khóa RESERVED, lệnh sẽ thất bại ngay lập tức (hoặc chờ theo busy_timeout), ngăn ngừa tình trạng Deadlock giữa hai giao dịch.
c. Kiến trúc Write Queue (Hàng đợi Ghi)
Trong kiến trúc Enterprise (Node.js, Go, Python...), giải pháp triệt để là tách riêng luồng đọc và luồng ghi:

Luồng Đọc (Read Operations): Sử dụng Connection Pool với nhiều kết nối ở chế độ Read-Only.
Luồng Ghi (Write Operations): Đưa toàn bộ các thao tác ghi vào một Single-worker Queue (Hàng đợi đơn luồng) để đảm bảo tại một thời điểm chỉ có đúng 1 connection thực hiện ghi vào SQLite.

1. Nguyên nhân gây ra lỗi SQLITE_BUSY

Mở Khóa Full Câu Trả Lời & Code Chuẩn Senior

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi SQLite liên quan cùng chủ đề