Về cơ bản, tôi có một ứng dụng có 5 chủ đề, mỗi chủ đề được đọc từ một bảng. Truy vấn là một SELECT TOP 1 * đơn giản từ bảng, nhưng tôi muốn thực thi một khóa để chuỗi tiếp theo sẽ chọn bản ghi tiếp theo từ bảng và không phải là bản ghi bị khóa. Khi ứng dụng đã hoàn thành nhiệm vụ của nó, nó sẽ cập nhật bản ghi bị khóa và giải phóng khóa và lặp lại quá trình này một lần nữa. Điều này có thể không?Khóa hàng - theo cách thủ công sử dụng chúng
Cách tiếp cận tôi khuyên bạn nên có một trường trong bản ghi dọc theo các dòng cho biết liệu bản ghi có đang được xử lý hay không. Sau đó thực hiện một "đọc tiếp theo từ hàng đợi" sproc rằng nào sau đây, để đảm bảo không có 2 quá trình nhặt cùng một kỷ lục:
BEGIN TRANSACTION
-- Find the next available record that's not already being processed.
-- The combination of UPDLOCK and READPAST hints makes sure 2 processes don't
-- grab the same record, and that processes don't block each other.
SELECT TOP 1 @ID = ID
FROM YourTable WITH (UPDLOCK, READPAST)
WHERE BeingProcessed = 0
-- If we've found a record, set it's status to "being processed"
IF (@ID IS NOT NULL)
UPDATE YourTable SET BeingProcessed = 1 WHERE ID = @ID
COMMIT TRANSACTION
-- Finally return the record we've picked up
IF (@ID IS NOT NULL)
SELECT * FROM YourTable WHERE ID = @ID
Để biết thêm về những gợi ý bảng, xem MSDN
Cảm ơn bạn đã phản hồi nhanh. Tôi có phải làm báo cáo cập nhật ngay lập tức không? Nếu tôi cam kết giao dịch sau khi CHỌN, điều đó có để lại KHÓA tại chỗ không? –
Không khóa sẽ không được giữ nguyên. – AdaTheDev
Vâng, đây là SQL Server, 2008 là chính xác. Vì vậy, tôi cần phải bắt đầu một giao dịch trong ứng dụng, chọn bản ghi, thực hiện việc xử lý cần thiết trong ứng dụng và cập nhật bản ghi và cam kết giao dịch để giữ cho hàng bị khóa? –
Service Broker Queues trong Sql Server được thiết kế đặc biệt để giải quyết kịch bản này.
Việc khóa bàn và hàng có vẻ giống như một cách ngược để đạt được chức năng này.
Xem [WHY NOT USE BUILT-IN QUEUES?] (Http://rusanu.com/2010/03/26/using-tables-as-queues/) –
Các đối số khá tốt, nhưng 1) xác nhận rằng chúng khó sử dụng là ngớ ngẩn, đơn giản là không. Nó có thể dễ dàng hơn, nhưng chắc chắn là không khó. 2) Tôi đồng ý, sẽ rất tốt nếu có cấu trúc linh hoạt. 3) Việc thiếu bảo trì sẽ chỉ là vấn đề thực sự trong các trường hợp đặc biệt ~ 3.000 + msg/s. Tôi sẽ tranh luận trong trường hợp đó nó là một vấn đề thiết kế hơn là sự thất bại của công nghệ. Hơn nữa, giải pháp được đề xuất ở trên sẽ không phá vỡ vấn đề phân mảnh, nhưng sẽ dễ giải quyết hơn. –
Tác giả bài viết là một trong những nhà phát triển môi giới dịch vụ vì vậy nếu họ khuyên bạn nên sử dụng các bảng như hàng đợi tùy thuộc vào nhà môi giới dịch vụ, tôi có khuynh hướng coi đó là giá trị mặt. –
Nhiều bài viết chi tiết về techtique này "Xử lý dữ liệu hàng đợi trong SQL Server với READPAST và UPDLOCK"
tôi đã thực hiện một giả định này được SQL Server - không biết có đúng? – AdaTheDev