Trước hết, có một lỗi trong quá trình triển khai của bạn. Nếu truy vấn bị lỗi, giao dịch hiện tại sẽ tự động được khôi phục và sau đó được đóng lại. Vì vậy, khi bạn tiếp tục thực hiện các truy vấn, chúng sẽ không nằm trong một giao dịch (chúng sẽ được cam kết với DB). Sau đó, khi bạn thực thi Rollback , nó sẽ âm thầm thất bại. Từ tài liệu MySQL
:
Rolling back can be a slow operation that may occur implicitly without the user
having explicitly asked for it (for example, when an error occurs).
Lệnh rõ ràng ROLLBACK chỉ nên được sử dụng nếu bạn xác định trong ứng dụng mà bạn cần khôi phục (vì các lý do khác ngoài lỗi truy vấn). Ví dụ:nếu bạn đang khấu trừ tiền từ một tài khoản, bạn sẽ hoàn lại một cách rõ ràng nếu bạn phát hiện ra rằng người dùng không có đủ tiền để hoàn tất việc trao đổi ...
Đối với việc kiểm tra các giao dịch, tôi sao chép cơ sở dữ liệu. Tôi tạo một cơ sở dữ liệu mới và cài đặt một bộ "dữ liệu giả". Sau đó, tôi chạy tất cả các bài kiểm tra bằng một công cụ tự động. Công cụ sẽ thực sự cam kết các giao dịch và buộc khôi phục, đồng thời kiểm tra xem trạng thái cơ sở dữ liệu dự kiến có được duy trì trong suốt quá trình kiểm tra hay không. Vì việc lập trình để biết trạng thái kết thúc từ một giao dịch sẽ khó hơn nếu bạn có đầu vào không xác định cho giao dịch, nên việc kiểm tra dữ liệu trực tiếp (hoặc thậm chí được sao chép từ trực tiếp) sẽ không dễ dàng. Bạn có thể làm điều đó (và nên làm), nhưng đừng phụ thuộc vào những kết quả đó để xác định xem hệ thống của bạn có hoạt động hay không. Sử dụng những kết quả đó để xây dựng các trường hợp thử nghiệm mới cho trình thử nghiệm tự động ...
