নির্বাচন-আপডেটের প্যাটার্ন ব্যবহার করার সময় সম্মতি পরিচালনা করা


25

আসুন ধরে নিন যে আপনার নিম্নলিখিত কোড রয়েছে (দয়া করে এটিকে ঘৃণা করুন তা উপেক্ষা করুন):

BEGIN TRAN;
DECLARE @id int
SELECT @id = id + 1 FROM TableA;
UPDATE TableA SET id = @id; --TableA must have only one row, apparently!
COMMIT TRAN;
-- @id is returned to the client or used somewhere else

আমার দৃষ্টিতে, এটি সামঞ্জস্যভাবে সঠিকভাবে পরিচালনা করছে না। কেবলমাত্র আপনার লেনদেন হওয়ার অর্থ এই নয় যে আপনার আপডেট বিবৃতি পাওয়ার আগে অন্য কেউ আপনার সমান মূল্য পড়বে না।

এখন, কোডটি যেমন রেখে দেওয়া হয়েছে (আমি বুঝতে পেরেছি এটি একটি একক বিবৃতি হিসাবে আরও ভালভাবে পরিচালনা করা হয়েছে বা স্বায়ত্তশাসন / পরিচয় কলাম ব্যবহার করা আরও ভাল) এটি সঠিকভাবে সামঞ্জস্য পরিচালনা করার উপায়গুলি এবং জাতি শর্তগুলি প্রতিরোধ করে যা দুটি ক্লায়েন্টকে একই পেতে দেয় আইডি মান?

আমি বেশ নিশ্চিত যে WITH (UPDLOCK, HOLDLOCK)নির্বাচনটিতে একটি যুক্ত করা কৌশলটি করবে। SERIALIZABLE লেনদেন বিচ্ছিন্নতা স্তর পাশাপাশি কাজ বলে মনে হয় হবে যেহেতু এটি অস্বীকার অন্য কেউ পর্যন্ত Tran শেষ হয়ে গেছে আপনি কি পড়তে ( আপডেট । এই মিথ্যা মার্টিন দেখি উত্তর)। এটা কি সত্যি? তারা দুজনেই কি সমানভাবে কাজ করবে? একজনের কি অন্যের চেয়ে বেশি পছন্দ হয়?

কোনও আইডি আপডেটের চেয়ে আরও বৈধ কিছু করার কল্পনা করুন - এমন একটি রিডের উপর ভিত্তি করে কিছু গণনা যা আপনাকে আপডেট করতে হবে। এতে অনেকগুলি সারণী জড়িত থাকতে পারে, যার মধ্যে কয়েকটি আপনি লিখবেন এবং অন্যগুলি যা আপনি পাবেন না। এখানে সেরা অনুশীলন কি?

এই প্রশ্নটি লেখার পরে, আমি মনে করি লক ইঙ্গিতগুলি আরও ভাল কারণ তবে আপনি কেবল আপনার প্রয়োজনীয় টেবিলগুলি লক করছেন তবে আমি যে কারও ইনপুটকে প্রশংসা করব।

পিএস এবং না, আমি সর্বোত্তম উত্তরটি জানি না এবং সত্যিই আরও ভাল বোঝা পেতে চাই! :)


কেবলমাত্র স্পষ্টতার জন্য: আপনি কি 2 ক্লায়েন্টকে একই মানটি পড়তে বা updateঅপ্রচলিত ডেটার উপর ভিত্তি করে প্রকাশ করতে বাধা দিতে চান ? পরে যদি হয়, আপনি rowversionকলামটি আপডেট করতে হবে কিনা তা পরীক্ষা করার জন্য এটি পড়ার পরে পরিবর্তন করা হয়নি।
a1ex07

আমরা চাই না যে দ্বিতীয় ক্লায়েন্ট পুরানো আইডি মান পাবে এটির প্রথম ক্লায়েন্ট দ্বারা নতুন মান আপডেট করার আগে। এটি ব্লক করা উচিত।
এরিক

উত্তর:


11

কেবল SERIALIZABLEবিচ্ছিন্নতা স্তরের দিকটি সম্বোধন করা । হ্যাঁ এটি কাজ করবে তবে অচলাবস্থার ঝুঁকির সাথে।

দুটি লেনদেন উভয়ই সারিবদ্ধভাবে পড়তে সক্ষম হবে। তারা একে অপরকে অবরুদ্ধ করবে না কারণ তারা হয় টেবিল কাঠামোর উপর নির্ভর করে কোনও অবজেক্ট Sলক বা সূচক লক নেবে RangeS-Sএবং এই লকগুলি সামঞ্জস্যপূর্ণ । আপডেটের জন্য প্রয়োজনীয় লকগুলি যথাক্রমে অর্জন করার চেষ্টা করার সময় তারা একে অপরকে অবরুদ্ধ করবে ( যথাক্রমে অবজেক্ট IXলক বা সূচক RangeS-U) যা অচলাবস্থার দিকে পরিচালিত করবে।

UPDLOCKপরিবর্তে একটি সুস্পষ্ট ইঙ্গিত ব্যবহার পঠনকে সিরিয়ালাইজ করবে যাতে অচলাবস্থার ঝুঁকি এড়ানো যায়।


+1 তবে: হিপ টেবিলগুলির জন্য আপনি আপডেট লক সহ এখনও রূপান্তর অচলাবস্থা পেতে পারেন: sqlblog.com/blogs/alexender_kuznetsov/archive/2009/03/11/…
একে

উদ্ভট, @ অ্যালেক্স আমি ভাবছি এটি ইঞ্জিনের একটি রেস শর্তের সাথে আসলে কী তা তালাবদ্ধ করার চেষ্টা করছে তা বাস্তবে এটি আপলোড করুন ...
এরিক

@ErikE - Alex এর প্রবন্ধে রূপান্তর অচলাবস্থা থেকে রূপান্তর করা হয় IXথেকে Xগাদা নিজেই করেন। মজার বিষয় হল যে কোনও সারি কোয়ালিফাই করে না তাই কোনও সারির লকগুলি কখনই বাইরে না নিয়ে আসে। কেন এটি মোটেই Xলক নেয় তা নিশ্চিত নয় Not
মার্টিন স্মিথ

11

আমি মনে করি আপনার পক্ষে সর্বোত্তম পন্থা হ'ল আপনার মডিউলটি প্রকৃতপক্ষে উচ্চ সম্মতিতে প্রকাশ করা এবং নিজের জন্য দেখুন। কখনও কখনও আপডলক একাই যথেষ্ট, এবং হোল্ডলকের প্রয়োজন নেই। কখনও কখনও sp_getapplock খুব ভাল কাজ করে। আমি এখানে কোনও কম্বল বিবৃতি দেব না - কখনও কখনও আরও একটি সূচক, ট্রিগার, বা সূচিযুক্ত ভিউ যুক্ত করে ফলাফল পরিবর্তন করে। আমাদের পরীক্ষার কোডে চাপ দেওয়া এবং কেস ভিত্তিতে কেস হিসাবে আমাদের নিজেরাই দেখতে হবে।

আমি এখানে স্ট্রেস টেস্টিংয়ের বেশ কয়েকটি উদাহরণ লিখেছি

সম্পাদনা করুন: ইন্টার্নালগুলির আরও ভাল জ্ঞানের জন্য, আপনি ক্যালেন ডেলানির বইগুলি পড়তে পারেন। তবে বইগুলি অন্যান্য ডকুমেন্টেশনের মতোই সিঙ্কের বাইরে চলে যেতে পারে। এছাড়াও, বিবেচনা করার মতো অনেকগুলি সংমিশ্রণ রয়েছে: ছয়টি বিচ্ছিন্নতা স্তর, বহু ধরণের তালা, গুচ্ছ / নন-ক্লাস্টার্ডড সূচক এবং কে কী জানে। এটি প্রচুর সংমিশ্রণ। তার উপরে, এসকিউএল সার্ভারটি বন্ধ উত্স, তাই আমরা উত্স কোডটি ডাউনলোড করতে পারি না, এটি ডিবাগ করতে পারি এবং এ জাতীয় - এটি জ্ঞানের চূড়ান্ত উত্স হবে। পরবর্তী কিছু প্রকাশ বা পরিষেবা প্যাকের পরে অন্য যে কোনও কিছুই অসম্পূর্ণ বা পুরানো হতে পারে।

সুতরাং, আপনার নিজের স্ট্রেস টেস্টিং ছাড়া আপনার সিস্টেমে কী কাজ করে তা সিদ্ধান্ত নেওয়া উচিত নয়। আপনি যা যা পড়েছেন, এটি আপনাকে কী হতে চলেছে তা বুঝতে সহায়তা করতে পারে তবে আপনি যে প্রমাণটি পড়েছেন তা আপনার পক্ষে কার্যকর হয় তা প্রমাণ করতে হবে। আমি মনে করি না কেউ আপনার জন্য এটি করতে পারে।


9

এই বিশেষ ক্ষেত্রে একটি UPDLOCKলক যোগ SELECTপ্রকৃতপক্ষে অস্বাভাবিকতা রোধ করবে। HOLDLOCKলেনদেনের সময়কালের জন্য আপডেট লক থাকায় সংযোজন প্রয়োজনীয় নয়, তবে আমি নিজেকে এটি অতীতে একটি (সম্ভবত খারাপ) অভ্যাস হিসাবে অন্তর্ভুক্ত করার স্বীকার করি।

কোনও আইডি আপডেটের চেয়ে আরও বৈধ কিছু করার কল্পনা করুন, এমন একটি পঠনের ভিত্তিতে কিছু গণনা যা আপনাকে আপডেট করতে হবে। এতে অনেকগুলি সারণী জড়িত থাকতে পারে, যার মধ্যে কয়েকটি আপনি লিখবেন এবং অন্যগুলি যা আপনি পাবেন না। এখানে সেরা অনুশীলন কি?

এর চেয়ে সেরা অনুশীলন নেই। আপনার সম্মতি নিয়ন্ত্রণের পছন্দটি প্রয়োগের প্রয়োজনীয়তার উপর ভিত্তি করে তৈরি করা উচিত। কিছু অ্যাপ্লিকেশন / লেনদেনের কার্যকর করতে হবে যেন তাদের ডেটাবেসটির একচেটিয়া মালিকানা ছিল, যাবতীয় ব্যয়ে অসঙ্গতি এবং অসম্পূর্ণতা এড়ানো। অন্যান্য অ্যাপ্লিকেশন / লেনদেন একে অপরের কাছ থেকে কিছুটা হস্তক্ষেপ সহ্য করতে পারে।

  • একটি ওয়েব স্টোরের একটি পণ্যের জন্য ব্যান্ডযুক্ত স্টক স্তর (<5, 10+, 50+, 100+) পুনরুদ্ধার করা = নোংরা পঠন (ভুল বিষয় নয়)।
  • সেই ওয়েব স্টোর চেকআউটতে স্টক স্তর চেক করা এবং হ্রাস করা = পুনরাবৃত্তিযোগ্য পঠন (আমরা বিক্রি করার আগে আমাদের স্টক থাকা উচিত, আমাদের নেতিবাচক স্টক স্তরটি শেষ করা উচিত নয়)।
  • ব্যাঙ্কে আমার বর্তমান এবং সঞ্চয়ী অ্যাকাউন্টের মধ্যে নগদ সরিয়ে নেওয়া = সিরিয়ালাইজযোগ্য (আমার নগদকে ভুলভাবে গণনা বা ভুল জায়গায় স্থাপন করবেন না)।

সম্পাদনা: @ অ্যালেক্সকুজনসভের মন্তব্যটি আমার পুনরায় পড়ার এবং আমার উত্তরের খুব সুস্পষ্ট ত্রুটি অপসারণের জন্য বলেছে। গভীর রাতে পোস্টে নিজের কাছে নোট করুন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.