দ্বন্দ্বগুলি মোকাবেলা করার সময় আপনার কাছে দুটি বিকল্প রয়েছে:
- আপনি দ্বন্দ্ব এড়ানোর চেষ্টা করতে পারেন, এবং হতাশাবাদী লকিং এটাই করে।
- অথবা, আপনি দ্বন্দ্ব সংঘটিত হতে দিয়েছিলেন, তবে আপনার লেনদেন করার সময় আপনাকে এটি সনাক্ত করতে হবে এবং আশাবাদী লকিং এটাই করে।
এখন, আসুন নিম্নলিখিত হারানো আপডেট বিবেচনা করুন :
হারানো আপডেট বিচ্ছিন্নতা পড়ুন প্রতিশ্রুতিবদ্ধ বিচ্ছিন্নতা স্তরে ঘটতে পারে ।
উপরের চিত্রটিতে আমরা দেখতে পাচ্ছি যে অ্যালিস বিশ্বাস করেন যে তিনি তার কাছ থেকে 40 ফিরিয়ে নিতে পারবেন accountতবে বুঝতে পারেন না যে বব অ্যাকাউন্টের ব্যালেন্সটি সবেমাত্র বদলেছে, এবং এখন এই অ্যাকাউন্টে 20 টি বাকী রয়েছে।
হতাশাবাদী লকিং
হতাশাবাদী লকিং অ্যাকাউন্টে একটি ভাগ বা পড়া তালা নিয়ে এই লক্ষ্য অর্জন করে যাতে বব অ্যাকাউন্টটি পরিবর্তন থেকে রোধ করা হয়।
উপরের চিত্রটিতে, অ্যালিস এবং বব accountউভয়ই সারণী সারিটিতে একটি পঠিত লক অর্জন করবে যা উভয় ব্যবহারকারীই পড়েছেন have পুনরাবৃত্তিযোগ্য পড়ুন বা সিরিয়ালাইজযোগ্য ব্যবহার করার সময় ডাটাবেসটি এসকিউএল সার্ভারে এই লকগুলি অর্জন করে।
কারণ অ্যালিস এবং বব উভয়ই accountপিকে মানটির সাথে পড়েছেন 1, কোনও ব্যবহারকারী পঠিত লক প্রকাশ না করা পর্যন্ত উভয়ই এটিকে পরিবর্তন করতে পারবেন না। এটি কারণ লেখার ক্রিয়াকলাপের জন্য একটি লিখন / একচেটিয়া লক অধিগ্রহণ প্রয়োজন হয় এবং ভাগ / পঠিত লকগুলি রাইটিং / এক্সক্লুসিভ লকগুলি রোধ করে।
অ্যালিস তার লেনদেনের প্রতিশ্রুতিবদ্ধ হওয়ার পরে এবং পাঠ্য তালাটি accountসারিতে প্রকাশিত হওয়ার পরে , বব UPDATEআবার পরিবর্তন শুরু করবে এবং পরিবর্তনটি প্রয়োগ করবে। অ্যালিস পঠিত লক প্রকাশ না হওয়া অবধি, বব'র আপডেট আপডেট অবরুদ্ধ।
ডেটা অ্যাক্সেস ফ্রেমওয়ার্কগুলি কীভাবে অন্তর্নিহিত ডেটাবেস হতাশাবাদী লকিং সমর্থন ব্যবহার করে সে সম্পর্কে আরও তথ্যের জন্য এই নিবন্ধটি দেখুন ।
আশাবাদী লকিং
আশাবাদী লকিং দ্বন্দ্ব সংঘটিত হতে দেয় তবে সংস্করণ পরিবর্তিত হওয়ায় এটি এলিসের আপডেটের প্রয়োগের পরে সনাক্ত করে।
এবার, আমাদের একটি অতিরিক্ত versionকলাম রয়েছে। versionকলাম প্রত্যেক সময় একটি আপডেট মান বৃদ্ধি হয় বা মুছতে মৃত্যুদন্ড কার্যকর করা হয়, এবং এটি কোথায় আপডেট এবং মুছে বিবৃতি দফা ব্যবহার করা হয়। এটি কাজ করার জন্য, আমাদের versionআপডেট বা ডিলিটের কার্যকর করার আগে আমাদের নির্বাচন বাছাই করা এবং বর্তমানটি পড়া দরকার , অন্যথায় হিসাবে, আমরা জানতাম না যে বিভাজনটির মানটি কোথায় বা ক্লাসে পাস করতে হবে।
কীভাবে ডেটা অ্যাক্সেস ফ্রেমওয়ার্কগুলি আশাবাদী লকিং বাস্তবায়িত করে সে সম্পর্কে আরও তথ্যের জন্য, এই নিবন্ধটি দেখুন ।
অ্যাপ্লিকেশন-স্তরের লেনদেন
রিলেশনাল ডাটাবেস সিস্টেমগুলি 70 এর দশকের শেষের দিকে আবির্ভূত হয় যখন কোনও ক্লায়েন্ট সাধারণত টার্মিনালের মাধ্যমে একটি মেইনফ্রেমে সংযুক্ত হন। এজন্য আমরা এখনও ডেটাবেস সিস্টেমগুলিকে SESSION সেটিংয়ের মতো পদগুলি সংজ্ঞায়িত করতে দেখি।
আজকাল, ইন্টারনেটে, আমরা আর একই ডাটাবেস লেনদেনের প্রসঙ্গে পড়তে এবং লেখার প্রয়োগ করি না, এবং এসিডি আর পর্যাপ্ত থাকে না।
উদাহরণস্বরূপ, নিম্নলিখিত ব্যবহারের ক্ষেত্রে বিবেচনা করুন:
আশাবাদী লকিং ব্যতীত, ডাটাবেস লেনদেন সিরিয়ালাইজেবল ব্যবহার করা হলেও এই হারানো আপডেটটি ধরা পড়ার কোনও উপায় নেই। এটি কারণ এই যে পাঠ্য এবং লেখাগুলি পৃথক এইচটিটিপি অনুরোধে কার্যকর করা হয়, তাই বিভিন্ন ডাটাবেস লেনদেনে on
সুতরাং, আশাবাদী লকিং অ্যাপ্লিকেশন-স্তরের লেনদেনগুলি ব্যবহার করে এমনকি ব্যবহারকারী-চিন্তার সময়কে অন্তর্ভুক্ত করার পরেও হারানো আপডেটগুলি প্রতিরোধ করতে সহায়তা করতে পারে।
অ্যাপ্লিকেশন-স্তর বা যৌক্তিক লেনদেন সম্পর্কে আরও তথ্যের জন্য, এই নিবন্ধটি দেখুন ।
উপসংহার
আশাবাদী লক করা একটি খুব কার্যকর কৌশল, এবং পড়ুন প্রতিশ্রুতিবদ্ধ যেমন কম-কঠোর বিচ্ছিন্নতা স্তর ব্যবহার করার পরে, বা পরবর্তী ডাটাবেস লেনদেনে যখন পড়া এবং লেখার সম্পাদন করা হয় তখনও এটি ঠিক কাজ করে।
আশাবাদী লকিংয়ের অবক্ষয়টি হ'ল এটি ধরার পরে ডেটা অ্যাক্সেস ফ্রেমওয়ার্কের মাধ্যমে একটি রোলব্যাক ট্রিগার করা হবে OptimisticLockException, অতএব আমরা বর্তমানে সম্পাদনকারী লেনদেনের মাধ্যমে আমরা পূর্বে যে সমস্ত কাজ করেছি তা হারিয়েছি।
আরও বিতর্ক, আরও দ্বন্দ্ব এবং লেনদেন বাতিল করার সম্ভাবনা তত বেশি। রোলব্যাকগুলি ডাটাবেস সিস্টেমের জন্য ব্যয়বহুল হতে পারে কারণ এটি সমস্ত বর্তমান মুলতুবি পরিবর্তনগুলি ফিরিয়ে আনতে হবে যা টেবিল সারি এবং সূচক রেকর্ড উভয়ই জড়িত থাকতে পারে।
এই কারণে, ঘনঘন সংঘাত ঘটে যখন হতাশাবাদী লকিং আকরিক উপযুক্ত হতে পারে, কারণ এটি লেনদেন ঘূর্ণায়মান সম্ভাবনা হ্রাস করে।