मूल रूप से एक ऐसा अनुप्रयोग है जिसमें 5 धागे हैं, जो प्रत्येक तालिका से पढ़ते हैं। क्वेरी तालिका से एक साधारण चयन शीर्ष 1 * है, लेकिन मैं लॉक को लागू करना चाहता हूं ताकि अगला थ्रेड तालिका से अगले रिकॉर्ड का चयन करेगा और लॉक नहीं होगा। जब एप्लिकेशन ने अपना काम पूरा कर लिया है, तो यह लॉक रिकॉर्ड अपडेट करेगा और लॉक जारी करेगा और प्रक्रिया को फिर से दोहराएगा। क्या यह संभव है?पंक्ति ताले - मैन्युअल रूप से उनका उपयोग
जिस तरह का दृष्टिकोण मैं सुझाता हूं वह इस रिकॉर्ड के साथ रिकॉर्ड में एक फ़ील्ड रखना है कि यह इंगित करता है कि रिकॉर्ड संसाधित हो रहा है या नहीं। फिर, एक "अगले कतार से पढ़ें" sproc निम्न करता है को लागू सुनिश्चित करने के लिए कोई 2 प्रक्रियाओं एक ही रिकॉर्ड लेने:
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
इन तालिका संकेत बारे में अधिक जानकारी के लिए, देखें MSDN
त्वरित प्रतिक्रिया के लिए धन्यवाद। क्या मुझे तुरंत अपडेट स्टेटमेंट करना होगा? अगर मैंने चयन के बाद लेनदेन किया, तो क्या वह LOCK को जगह में छोड़ देगा? –
कोई लॉक जगह में नहीं रहेगा। – AdaTheDev
हां, यह सटीक होने के लिए SQL सर्वर, 2008 है। तो, मुझे आवेदन के भीतर एक लेनदेन शुरू करना होगा, रिकॉर्ड का चयन करना होगा, आवेदन में आवश्यक प्रसंस्करण करना होगा और रिकॉर्ड को अपडेट करना होगा और पंक्ति को लॉक रखने के लिए लेनदेन करना होगा? –
में Service Broker Queues एसक्यूएल सर्वर विशेष रूप से इस परिदृश्य को संबोधित करने के लिए डिजाइन किए गए थे।
टेबल और पंक्तियों को लॉक करने के लिए इस कार्यक्षमता को प्राप्त करने के लिए पीछे की ओर लगता है।
देखें [क्यों उपयोग नहीं करते हैं?] (Http://rusanu.com/2010/03/26/using-tables-as-queues/) –
तर्क काफी अच्छे हैं, लेकिन 1) दावा है कि वे उपयोग करना मुश्किल है मूर्खतापूर्ण है, वे बस नहीं हैं। यह आसान हो सकता है, लेकिन यह निश्चित रूप से कठिन नहीं है। 2) मैं मानता हूं, एक लचीली संरचना होना अच्छा लगेगा। 3) रखरखाव की कमी असाधारण मामलों ~ 3,000 + msg/s में वास्तविक समस्या होगी। मैं उस मामले में बहस करता हूं कि यह प्रौद्योगिकी की विफलता की तुलना में एक डिजाइन मुद्दा है। इसके अलावा, ऊपर सुझाए गए समाधान विखंडन की समस्या को बाधित नहीं करेंगे, लेकिन हल करना आसान होगा। –
लेख लेखक सेवा ब्रोकर डेवलपर्स में से एक था, इसलिए यदि वे सेवा ब्रोकर को प्राथमिकता में कतार के रूप में टेबल का उपयोग करने की सलाह देते हैं तो मैं इसे अंकित मूल्य के रूप में लेने के इच्छुक हूं। –
अधिक विस्तार "READPAST साथ प्रसंस्करण डाटा कतार एसक्यूएल सर्वर में और UPDLOCK" इस techtique
मैं इस धारणा बना के बारे में लेख है एसक्यूएल सर्वर - सही है? – AdaTheDev