কোনও ব্যবহারকারী দ্বারা সম্পাদিত হওয়ার সময় আমি কি আমার ক্লাউড ডিবিতে সারিগুলি লক করা উচিত?


12

আমি একটি ডেস্কটপ অ্যাপ্লিকেশন তৈরি করছি যা মেঘের মধ্যে থাকা ডেটা ধরে রাখে। আমার উদ্বেগের একটি বিষয় হ'ল অ্যাপ্লিকেশনটিতে কোনও আইটেম সম্পাদনা করা এবং ডেটাটি বাসি হয়ে যাওয়ার ফলে কিছুক্ষণের জন্য রেখে দেওয়া। 2 জন ব্যক্তি একই সময়ে একই আইটেমটি সম্পাদনা করার চেষ্টা করলে এটি স্পষ্টতই ঘটতে পারে। যখন তারা তাদের সম্পাদনা শেষ করে এবং ডেটা সংরক্ষণ করতে চায় তখন আমার প্রয়োজন হয় বর্তমানে ডাটাবেসে বিদ্যমান যা ওভাররাইট করা দরকার বা তারা শেষ পরিবর্তনের পরে সম্পাদনা শুরু করেছিল এবং তাদের পরিবর্তনগুলি বাতিল করতে বাধ্য করতে পারে বা তাদের ঝুঁকির বিকল্প দিতে পারে অন্য কারোর পরিবর্তনগুলি ওভাররাইট করা।

আমি একটি ক্ষেত্র যোগ সম্পর্কে চিন্তা is_lockedএবং lock_timestampডিবি টেবিলে। যখন কোনও ব্যবহারকারী আইটেমটি সম্পাদনা করা শুরু করে তখন সারিটি is_lockedসত্যে পরিবর্তিত হয়ে বর্তমান সময়ের জন্য লক টাইমস্ট্যাম্প সেট করে। তারপরে আমার কাছে কিছু সময় লাগবে যার জন্য লকটি রাখা হয় (উদা। 5 মিনিট)। অন্য কেউ যদি আইটেমটি সম্পাদনা করার চেষ্টা করেন তারা আইটেমটি লক করা আছে এবং যখন লকটি স্বয়ংক্রিয়ভাবে শেষ হবে তখন একটি বার্তা পাবেন। লক সম্পাদনার সময় ব্যবহারকারী দূরে চলে গেলে অপেক্ষাকৃত স্বল্প সময়ের পরে স্বয়ংক্রিয়ভাবে মেয়াদ শেষ হয়ে যায় এবং একবার ব্যবহারকারীকে সতর্ক করা হবে যে লকটির মেয়াদ শেষ হয়ে গেছে এবং ডেটা রিফ্রেশ হওয়ার পরে সম্পাদনা পুনরায় চালু করতে বাধ্য করা হবে।

ওভাররাইটিং বাসি ডেটা রোধ করার জন্য এটি কি ভাল পদ্ধতি হবে? এটি কি ওভারকিল (আমি আশা করি না যে অ্যাপ্লিকেশনটি একক অ্যাকাউন্টে একযোগে কয়েকটি বেশি লোক ব্যবহার করবে) used

(আমার আর একটি উদ্বেগের বিষয় হ'ল 2 জন একই আইটেমটির জন্য একটি লক পেয়েছে, তবে আমি বিশ্বাস করি যে এটি এমন একটি জাতি শর্ত যা আমি স্বাচ্ছন্দ্যবোধ করি))


1
"আমার আরেকটি উদ্বেগ হ'ল 2 জন একই আইটেমটির জন্য একটি লক পেয়েছে, তবে আমি বিশ্বাস করি যে এটি এমন একটি জাতি শর্ত যা আমি স্বাচ্ছন্দ্য বোধ করি" - লকটি অর্জনের আশেপাশে একটি ডাটাবেস লেনদেন ব্যবহার করে এই জাতীয় দৌড় প্রতিরোধ করা উচিত।
জুলাই

বেশিরভাগ ডাটাবেস ইঞ্জিন (কমপক্ষে রিলেশনাল সাজানোর) এর সমর্থনে তৈরি করেছে। এটি আরডিবিএমএস জগতের একটি খুব সাধারণ ধারণা এবং এমনকি "খেলনা" ডাটাবেসগুলি এটি যথেষ্টভাবে পরিচালনা করে, আপনি যদি বলেন যে আপনি আশাবাদী বা নিরাশাবাদী লকিং চান। যাইহোক, আমি মনে করি না এটি যে কোনও উপায়ে নিজেকে তৈরি করার দরকার এটি এমন কিছু: আপনার ডিবি ইঞ্জিনের সাথে কীভাবে কাজ করা যায় তা পরীক্ষা করে দেখুন check
জেলে

আপনার অ্যাপ্লিকেশনটি একটি ডেস্কটপ অ্যাপ্লিকেশন (একটি ফ্যাট ক্লায়েন্ট ) আসলে খুব বেশি পার্থক্য করে না। এটি উচ্চ-উপলভ্য, মাল্টি-ইনস্ট্যান্স সার্ভার অ্যাপ্লিকেশন হিসাবে একইভাবে ডিজাইন করা যেতে পারে।
হোসাম অলি

উত্তর:


19

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

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

আপনি যে প্রকল্পটি রেখেছিলেন তা লক মানটির জন্য আশাবাদী লকিং প্রয়োগ করে ব্যাপকভাবে উন্নত হবে তবে আমার কুঁড়িটি হ'ল আশাবাদী লকিং পুরো জিনিসটির জন্য সম্ভবত ঠিক আছে এবং আপনি is_lock ক্ষেত্র থেকে মুক্তি পেতে পারেন।

আপনি কী 'ক্লাউড ডিবি' ব্যবহার করছেন তা সরবরাহ করেন না। আপনার নিজের সমাধান প্রয়োগের আগে সম্ভবত এর জন্য অন্তর্নির্মিত বৈশিষ্ট্য রয়েছে কিনা তা দেখতে আপনার বৈশিষ্ট্যগুলি খতিয়ে দেখা উচিত।

এখানে বেসিক রেসিপিটি দেওয়া হয়েছে: একটি আই-লক করা ক্ষেত্রের পরিবর্তে সংস্করণ নম্বর ক্ষেত্র রয়েছে। আপনি যখন রেকর্ডটি পুনরুদ্ধার করবেন, আপনি রেকর্ডটির বর্তমান সংস্করণটি টানবেন। আপনি যখন আপডেট করেন, আপনি যা পুনরুদ্ধার করেছেন তার সাথে মিল রেখে সংস্করণ ক্ষেত্রের আপডেট আপডেটটি তৈরি করে এবং সাফল্যে এটি বৃদ্ধি করে। সংস্করণটি মেলে না, আপডেটটির কোনও প্রভাব নেই এবং আপনি ব্যর্থতা হিসাবে এটি পুনরায় রিপোর্ট করবেন।


এটি একটি খুব সহায়ক উত্তর। "সংঘর্ষ" হওয়ার সামান্য সুযোগ পেলে হতাশাবাদী লক কেন নিরুৎসাহিত করা যায় তা আপনি ব্যাখ্যা করতে পারেন? এটি কি নিখুঁত কারণে যে এটির সম্পাদনা শুরু করার জন্য, বা অতিরিক্ত জটিলতা বা অন্য কোনও কারণে ডেটাবেজে যাওয়া দরকার? ধন্যবাদ!
yitzih

3
@ ইয়িটজিহ কিছু পড়ার পরামর্শ দিয়েছেন: ফওলার এট আল, এন্টারপ্রাইজ অ্যাপ্লিকেশন আর্কিটেকচারের প্যাটার্নস । এই অপশনের একটি সম্পূর্ণ অধ্যায় রয়েছে, সমস্ত অপশন এবং সেগুলি নির্বাচনের কারণ সম্পর্কে ভাল আলোচনা করে।
জুলাই

2
@ জিমি - আপনার উত্তর ঠিক আছে। কিছু ক্ষেত্রে, ত্রুটি ফিরিয়ে প্রতিবেদন করা আমার পক্ষে পর্যাপ্ত নয়। কোনও ক্ষেত্রে বিবেচনা করুন যখন কোনও ব্যবহারকারী কোনও রেকর্ড আপডেট করতে কয়েক মিনিট ব্যয় করে। সেক্ষেত্রে কেবল ব্যর্থতা যথেষ্ট ভাল নাও হতে পারে, একজন ব্যবহারকারীকে অন্য ব্যবহারকারী দ্বারা প্রতিশ্রুতিবদ্ধদের সাথে তাদের প্রবাহের পরিবর্তনগুলি মার্জ করার সুযোগ দিতে পারে। আমার উচিত ছিল আশাবাদী লক আপনার প্রয়োজনের উপর নির্ভর করে সংঘাতের সমাধান প্রয়োজন হতে পারে
জন রেয়নর

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

2
@ নীল এটি সত্য এবং আমি আশা করি যে আশাবাদী বেশি উপযুক্ত হলে হতাশাবাদী লক কেন প্রায়ই ব্যবহৃত হয়। প্রায়শই কর্মপ্রবাহটি একেবারেই অসম্ভাব্য করে তোলে যে এখানে সংঘর্ষ রয়েছে।
জিমি জেমস

0

থেকে @ JimmyJames এর উত্তর , আমরা দেখতে পারি কিভাবে প্রশ্ন সম্পর্কে সত্যিই ব্যবহারকারীর অভিজ্ঞতা

এটি সব প্রসঙ্গে নির্ভর করে। একটি রেকর্ড আপডেট করতে কত সময় এবং প্রচেষ্টা লাগে? একাধিক ব্যবহারকারী একই দস্তাবেজটি কতবার আপডেট করতে চান?

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

যদি আপনার দস্তাবেজটি অত্যন্ত বিতর্কিত তবে সু-কাঠামোগত হয় তবে সম্ভবত আপনি তাদের পৃথক ক্ষেত্রগুলিকে 30-সেকেন্ডের ইনক্রিমেন্টে লক করার মঞ্জুরি দিতে পারেন, লকটি প্রসারিত করার জন্য একটি টাইমার বা একটি আপত্তিজনক নোটিফিকেশন দেখিয়ে।

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

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

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