আমরা সম্প্রতি এসকিউএল 2008 আর 2 থেকে ব্র্যান্ডের নতুন এসকিউএল 2014 সার্ভারগুলিতে আমাদের উত্পাদন উদাহরণগুলি স্থানান্তরিত করেছি। এখানে একটি আকর্ষণীয় দৃশ্য যা আমাদের পরিষেবা ব্রোকারের ব্যবহারের সাথে আমরা উন্মোচিত করেছি। সঙ্গে একটি ডাটাবেস বিবেচনা Broker Enabled = trueসঙ্গে MyServiceএবং MyQueue। বিষাক্ত বার্তা হ্যান্ডলিং এই সারিটিতে অক্ষম। সারিতে বার্তাগুলির সাথে কমপক্ষে 2 টি সক্রিয় কথোপকথন রয়েছে।
একটি প্রক্রিয়ায় (এসপিআইডি 100) সম্পাদন করুন:
BEGIN TRANSACTION;
DECLARE @conversation_group_id UNIQUEIDENTIFIER;
RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue;
নোট করুন যে আমরা লেনদেনটি উন্মুক্ত রেখেছি। কল্পনা করুন যে এটি একটি। নেট প্রোগ্রাম যা কিছু বাহ্যিক সংস্থার জন্য দীর্ঘ সময় অপেক্ষা করে। এর মাধ্যমে sys.dm_tran_locksআমরা দেখতে যে এই SPID কিউ উপর একটি নবম লক মঞ্জুর করা হয়েছে।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
একটি পৃথক প্রক্রিয়াতে (এসপিআইডি 101) পাঁচবার কার্যকর করুন :
BEGIN TRANSACTION;
DECLARE @conversation_group_id UNIQUEIDENTIFIER;
RECEIVE TOP (1) @conversation_group_id = conversation_handle FROM MyQueue;
ROLLBACK TRANSACTION;
এখানে মূল কীটি হ'ল আমরা পাঁচবার লেনদেনটি ফিরিয়ে আনছি । এটি বিল্ট ইন পয়জন মেসেজ হ্যান্ডলিংয়ের পটভূমি যুক্তিকে ট্রিগার করে । সারিটি অক্ষম না হওয়া অবস্থায় (কারণ এটি অক্ষম না করার জন্য কনফিগার করা হয়েছে), একটি পটভূমি টাস্ক এখনও কাজ করার চেষ্টা করে এবং একটি broker_queue_disabledইভেন্ট ফায়ার করে । সুতরাং এখন আমরা যদি sys.dm_tran_locksআবার জিজ্ঞাসা করি তবে আমরা একটি ভিন্ন এসপিআইডি দেখতে পাব (যার সাথে সম্পর্কিত BRKR TASK) কোনও এস-এম লকটিতে অপেক্ষা করা।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
| OBJECT | 277576027 | Sch-M | WAIT | 36 |
এখনও অবধি, সমস্ত কিছু বোধগম্য হয়।
অবশেষে, একটি আলাদা প্রক্রিয়াতে (এসপিআইডি 102), সেই সারিটি ব্যবহার করে কোনও পরিষেবাতে প্রেরণের চেষ্টা করুন:
BEGIN TRANSACTION;
DECLARE @ch uniqueidentifier;
BEGIN DIALOG @ch FROM SERVICE [MyService] TO SERVICE 'MyService';
SEND ON CONVERSATION @ch ('HELLO WORLD');
SENDকমান্ড অবরোধ করা হয়েছে। আমরা যদি আবার তাকান তবে sys.dm_tran_locksআমরা দেখতে পাই যে এই প্রক্রিয়াটি কোনও এস-এস লকটিতে অপেক্ষা করছে। কার্যকর করে sp_who2আমরা দেখতে পেলাম যে এসপিআইডি 102 এসপিআইডি 36 দ্বারা অবরুদ্ধ।
| type | resource_id | mode | status | spid |
| OBJECT | 277576027 | IX | GRANT | 100 |
| OBJECT | 277576027 | Sch-M | WAIT | 36 |
| OBJECT | 277576027 | Sch-S | WAIT | 102 |
কেন একটি এস-এস লক অপেক্ষা করছে এমন কোনও এস-এম লকটিতে অপেক্ষা করছে?
এসকিউএল ২০০৮ আর 2 এ এই আচরণটি সম্পূর্ণ আলাদা! এই একই একই পরিস্থিতিটি ব্যবহার করে, আমাদের এখনও অবধি-বাতিল-হওয়া ২০০৮ -২-এর দৃষ্টান্তগুলিতে চলমান, SENDকমান্ড সহ চূড়ান্ত ব্যাচটি অপেক্ষারত এস-এম লক দ্বারা আটকাবে না ।
এসকিউএল 2012 বা 2014 এ লকিংয়ের আচরণটি পরিবর্তিত হয়েছে? সম্ভবত এমন কোনও ডাটাবেস বা সার্ভার সেটিং রয়েছে যা এই লকিং আচরণকে প্রভাবিত করতে পারে?
SENDব্লক সময় চেক ইনিশিয়েটরের কিউ। লক্ষ্য কাতারে SENDঅবরুদ্ধ করবে না , এটি কেবল বাউন্স করে সরবরাহ করার জন্য ব্যবহার করবে । আপনি যদি দুজনকে আলাদা করেন (সর্বদা একটি ভাল ধারণা) আপনার সমস্যা হবে না। sys.transmission_queue