Distributed Transactions: Two-Phase Commit (2PC) এর গভীরে

আজকের ক্রমবর্ধমান আন্তঃসংযুক্ত বিশ্বে, অ্যাপ্লিকেশনগুলিকে প্রায়শই একাধিক, স্বাধীন সিস্টেম জুড়ে সংরক্ষিত ডেটার সাথে যোগাযোগ করতে হয়। এটি distributed transactions এর ধারণার জন্ম দেয়, যেখানে একটি একক লজিক্যাল অপারেশনের জন্য একাধিক ডেটাবেস বা পরিষেবা জুড়ে পরিবর্তন করা প্রয়োজন। এই ধরনের পরিস্থিতিতে ডেটা কনসিস্টেন্সি নিশ্চিত করা অত্যন্ত গুরুত্বপূর্ণ, এবং এটি অর্জনের জন্য সবচেয়ে সুপরিচিত প্রোটোকলগুলির মধ্যে একটি হল Two-Phase Commit (2PC)।

Distributed Transaction কি?

একটি distributed transaction হল একাধিক, ভৌগলিকভাবে বিচ্ছিন্ন সিস্টেমে সম্পাদিত ক্রিয়াকলাপের একটি সিরিজ, যা একটি একক অ্যাটমিক ইউনিট হিসাবে বিবেচিত হয়। এর মানে হল যে লেনদেনের মধ্যে সমস্ত ক্রিয়াকলাপ সফল হতে হবে (commit), অথবা কোনটিই হবে না (rollback)। এই "all or nothing" নীতি পুরো distributed system জুড়ে ডেটা ইন্টিগ্রিটি নিশ্চিত করে।

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

Two-Phase Commit (2PC) Protocol এর পরিচিতি

Two-Phase Commit (2PC) protocol হল একটি distributed algorithm যা একাধিক রিসোর্স ম্যানেজার (যেমন, ডেটাবেস) জুড়ে অ্যাটমিকিটি নিশ্চিত করে। এতে একটি কেন্দ্রীয় কোঅর্ডিনেটর এবং একাধিক পার্টিসিপেন্ট জড়িত থাকে, প্রত্যেকে একটি নির্দিষ্ট রিসোর্স পরিচালনার জন্য দায়ী। প্রোটোকলটি দুটি পৃথক পর্যায়ে কাজ করে:

Phase 1: Prepare Phase

এই পর্যায়ে, কোঅর্ডিনেটর লেনদেন শুরু করে এবং প্রতিটি পার্টিসিপেন্টকে লেনদেন কমিট বা রোলব্যাক করার জন্য প্রস্তুত হতে বলে। জড়িত পদক্ষেপগুলি হল:

1. Coordinator sends a Prepare Request: কোঅর্ডিনেটর সকল পার্টিসিপেন্টকে একটি "prepare" বার্তা পাঠায়। এই বার্তাটি ইঙ্গিত দেয় যে কোঅর্ডিনেটর লেনদেন কমিট করার জন্য প্রস্তুত এবং প্রতিটি পার্টিসিপেন্টকে প্রস্তুত হতে অনুরোধ করে।
2. Participants Prepare and Respond: প্রতিটি পার্টিসিপেন্ট prepare request গ্রহণ করে এবং নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে:
   • এটি লেনদেন কমিট বা রোলব্যাক করার জন্য প্রয়োজনীয় পদক্ষেপ নেয় (যেমন, redo/undo লগ লেখা)।
   • এটি কোঅর্ডিনেটরকে একটি "vote" ফেরত পাঠায়, যা "prepared to commit" (একটি "yes" vote) অথবা "cannot commit" (একটি "no" vote) নির্দেশ করে। "No" vote রিসোর্স সীমাবদ্ধতা, ডেটা ভ্যালিডেশন ব্যর্থতা, বা অন্যান্য ত্রুটির কারণে হতে পারে।

পার্টিসিপেন্টদের জন্য "yes" ভোট দেওয়ার পরে পরিবর্তনগুলি কমিট বা রোলব্যাক করার গ্যারান্টি দেওয়া অত্যন্ত গুরুত্বপূর্ণ। এর জন্য সাধারণত স্থিতিশীল স্টোরেজে (যেমন, ডিস্ক) পরিবর্তনগুলি সংরক্ষণ করা প্রয়োজন।

Phase 2: Commit or Rollback Phase

এই পর্যায়টি prepare phase এ প্রাপ্ত ভোটের উপর ভিত্তি করে কোঅর্ডিনেটর দ্বারা শুরু করা হয়। দুটি সম্ভাব্য ফলাফল রয়েছে:

Outcome 1: Commit

যদি কোঅর্ডিনেটর সমস্ত পার্টিসিপেন্ট থেকে "yes" ভোট পায়, তবে এটি লেনদেন কমিট করার সাথে এগিয়ে যায়।

1. Coordinator sends a Commit Request: কোঅর্ডিনেটর সকল পার্টিসিপেন্টকে একটি "commit" বার্তা পাঠায়।
2. Participants Commit: প্রতিটি পার্টিসিপেন্ট commit request গ্রহণ করে এবং লেনদেনের সাথে সম্পর্কিত পরিবর্তনগুলি তাদের রিসোর্সে স্থায়ীভাবে প্রয়োগ করে।
3. Participants Acknowledge: প্রতিটি পার্টিসিপেন্ট কমিট অপারেশন সফল হয়েছে কিনা তা নিশ্চিত করার জন্য কোঅর্ডিনেটরকে একটি ACKNOWLEDGMENT বার্তা পাঠায়।
4. Coordinator Completes: সমস্ত পার্টিসিপেন্ট থেকে ACKNOWLEDGMENT প্রাপ্তির পর, কোঅর্ডিনেটর লেনদেনটি সম্পন্ন হিসাবে চিহ্নিত করে।

Outcome 2: Rollback

যদি কোঅর্ডিনেটর কোনও পার্টিসিপেন্ট থেকে একটি "no" ভোট পায়, অথবা যদি এটি কোনও পার্টিসিপেন্ট থেকে প্রতিক্রিয়া পাওয়ার জন্য অপেক্ষা করতে সময় শেষ হয়ে যায়, তবে এটি লেনদেন রোলব্যাক করার সিদ্ধান্ত নেয়।

1. Coordinator sends a Rollback Request: কোঅর্ডিনেটর সকল পার্টিসিপেন্টকে একটি "rollback" বার্তা পাঠায়।
2. Participants Rollback: প্রতিটি পার্টিসিপেন্ট rollback request গ্রহণ করে এবং লেনদেনের প্রস্তুতির জন্য করা যেকোন পরিবর্তন ফিরিয়ে আনে।
3. Participants Acknowledge: প্রতিটি পার্টিসিপেন্ট রোলব্যাক অপারেশন সফল হয়েছে কিনা তা নিশ্চিত করার জন্য কোঅর্ডিনেটরকে একটি ACKNOWLEDGMENT বার্তা পাঠায়।
4. Coordinator Completes: সমস্ত পার্টিসিপেন্ট থেকে ACKNOWLEDGMENT প্রাপ্তির পর, কোঅর্ডিনেটর লেনদেনটি সম্পন্ন হিসাবে চিহ্নিত করে।

Illustrative Example: E-commerce Order Processing

একটি ই-কমার্স সিস্টেম বিবেচনা করুন যেখানে একটি অর্ডার ইনভেন্টরি ডেটাবেস আপডেট করা এবং একটি পৃথক পেমেন্ট গেটওয়ের মাধ্যমে পেমেন্ট প্রক্রিয়া করা জড়িত। এগুলি দুটি পৃথক সিস্টেম যা একটি distributed transaction-এ অংশগ্রহণ করতে হবে।

1. Prepare Phase:
   • ই-কমার্স সিস্টেম (কোঅর্ডিনেটর) ইনভেন্টরি ডেটাবেস এবং পেমেন্ট গেটওয়েতে একটি prepare request পাঠায়।
   • ইনভেন্টরি ডেটাবেস অনুরোধ করা আইটেমগুলি স্টকে আছে কিনা তা পরীক্ষা করে এবং সেগুলি রিজার্ভ করে। এটি সফল হলে "yes" ভোট দেয় অথবা স্টক শেষ হয়ে গেলে "no" ভোট দেয়।
   • পেমেন্ট গেটওয়ে পেমেন্টের প্রাক-অনুমোদন দেয়। এটি সফল হলে "yes" ভোট দেয় অথবা অনুমোদন ব্যর্থ হলে (যেমন, অপর্যাপ্ত তহবিল) "no" ভোট দেয়।
2. Commit/Rollback Phase:
   • Commit Scenario: যদি ইনভেন্টরি ডেটাবেস এবং পেমেন্ট গেটওয়ে উভয়ই "yes" ভোট দেয়, তবে কোঅর্ডিনেটর উভয়কেই একটি commit request পাঠায়। ইনভেন্টরি ডেটাবেস স্টকের পরিমাণ স্থায়ীভাবে হ্রাস করে এবং পেমেন্ট গেটওয়ে পেমেন্ট ক্যাপচার করে।
   • Rollback Scenario: যদি ইনভেন্টরি ডেটাবেস বা পেমেন্ট গেটওয়ের মধ্যে কোনও একটি "no" ভোট দেয়, তবে কোঅর্ডিনেটর উভয়কেই একটি rollback request পাঠায়। ইনভেন্টরি ডেটাবেস রিজার্ভ করা আইটেমগুলি ছেড়ে দেয় এবং পেমেন্ট গেটওয়ে প্রাক-অনুমোদন বাতিল করে।

Two-Phase Commit এর সুবিধা

• Atomicity: 2PC অ্যাটমিকিটি নিশ্চিত করে, যা নিশ্চিত করে যে সমস্ত অংশগ্রহণকারী সিস্টেম একসাথে লেনদেন কমিট বা রোলব্যাক করে, ডেটা কনসিস্টেন্সি বজায় রাখে।
• Simplicity: 2PC প্রোটোকল বোঝা এবং বাস্তবায়ন করা তুলনামূলকভাবে সহজ।
• Wide Adoption: অনেক ডেটাবেস সিস্টেম এবং ট্রানজেকশন প্রসেসিং সিস্টেম 2PC সমর্থন করে।

Two-Phase Commit এর অসুবিধা

• Blocking: 2PC ব্লকিং ঘটাতে পারে, যেখানে পার্টিসিপেন্টরা কোঅর্ডিনেটরের সিদ্ধান্ত নেওয়ার জন্য অপেক্ষা করতে বাধ্য হয়। যদি কোঅর্ডিনেটর ব্যর্থ হয়, পার্টিসিপেন্টরা অনির্দিষ্টকালের জন্য ব্লক হয়ে যেতে পারে, রিসোর্স ধরে রাখতে পারে এবং অন্যান্য লেনদেনকে এগিয়ে যেতে বাধা দিতে পারে। এটি উচ্চ-লভ্য সিস্টেমগুলিতে একটি উল্লেখযোগ্য উদ্বেগ।
• Single Point of Failure: কোঅর্ডিনেটর একটি একক ব্যর্থতার বিন্দু। যদি কোঅর্ডিনেটর কমিট বা রোলব্যাক অনুরোধ পাঠানোর আগে ব্যর্থ হয়, পার্টিসিপেন্টরা একটি অনিশ্চিত অবস্থায় পড়ে থাকে। এটি ডেটা অসঙ্গতি বা রিসোর্স ডেডলকের কারণ হতে পারে।
• Performance Overhead: প্রোটোকলের দ্বি-পর্যায়ের প্রকৃতি উল্লেখযোগ্য ওভারহেড তৈরি করে, বিশেষ করে ভৌগলিকভাবে distributed system-এ যেখানে নেটওয়ার্ক ল্যাটেন্সি বেশি। কোঅর্ডিনেটর এবং পার্টিসিপেন্টদের মধ্যে যোগাযোগের একাধিক রাউন্ড লেনদেন প্রক্রিয়াকরণের সময়কে উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে।
• Complexity in Handling Failures: কোঅর্ডিনেটর ব্যর্থতা বা নেটওয়ার্ক বিভাজন থেকে পুনরুদ্ধার করা জটিল হতে পারে, যার জন্য ম্যানুয়াল হস্তক্ষেপ বা পরিশীলিত পুনরুদ্ধার পদ্ধতির প্রয়োজন।
• Scalability Limitations: পার্টিসিপেন্টদের সংখ্যা বৃদ্ধির সাথে সাথে 2PC এর জটিলতা এবং ওভারহেড দ্রুত বৃদ্ধি পায়, যা বড় আকারের distributed system-এ এর স্কেলেবিলিটিকে সীমিত করে।

Two-Phase Commit এর বিকল্প

2PC এর সীমাবদ্ধতার কারণে, distributed transaction পরিচালনার জন্য বেশ কয়েকটি বিকল্প পদ্ধতি আবির্ভূত হয়েছে। এর মধ্যে রয়েছে:

• Three-Phase Commit (3PC): 2PC এর একটি সম্প্রসারণ যা কমিট সিদ্ধান্তের জন্য প্রস্তুতি নেওয়ার জন্য একটি অতিরিক্ত পর্যায় যুক্ত করে ব্লকিং সমস্যা সমাধানের চেষ্টা করে। তবে, 3PC এখনও ব্লকিংয়ের জন্য ঝুঁকিপূর্ণ এবং 2PC এর চেয়ে বেশি জটিল।
• Saga Pattern: একটি দীর্ঘ-চলমান লেনদেন প্যাটার্ন যা একটি distributed transaction কে স্থানীয় লেনদেনের একটি সিরিজে বিভক্ত করে। প্রতিটি স্থানীয় লেনদেন একটি একক পরিষেবা আপডেট করে। যদি একটি লেনদেন ব্যর্থ হয়, পূর্ববর্তী লেনদেনগুলির প্রভাব বাতিল করার জন্য ক্ষতিপূরণমূলক লেনদেনগুলি কার্যকর করা হয়। এই প্যাটার্নটি অবশেষে কনসিস্টেন্সি (eventual consistency) পরিস্থিতির জন্য উপযুক্ত।
• Two-Phase Commit with Compensating Transactions: গুরুতর অপারেশনের জন্য 2PC এবং কম গুরুতর অপারেশনের জন্য ক্ষতিপূরণমূলক লেনদেনের সমন্বয় করে। এই পদ্ধতিটি শক্তিশালী কনসিস্টেন্সি এবং পারফরম্যান্সের মধ্যে একটি ভারসাম্য বজায় রাখতে দেয়।
• Eventual Consistency: একটি কনসিস্টেন্সি মডেল যা সিস্টেমগুলির মধ্যে অস্থায়ী অসঙ্গতিগুলি অনুমোদন করে। ডেটা অবশেষে সামঞ্জস্যপূর্ণ হবে, তবে একটি বিলম্ব হতে পারে। এই পদ্ধতিটি কিছু স্তরের অসঙ্গতি সহ্য করতে পারে এমন অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত।
• BASE (Basically Available, Soft state, Eventually consistent): নীতির একটি সেট যা শক্তিশালী কনসিস্টেন্সির চেয়ে প্রাপ্যতা এবং পারফরম্যান্সকে অগ্রাধিকার দেয়। BASE নীতি অনুসারে ডিজাইন করা সিস্টেমগুলি ব্যর্থতার বিরুদ্ধে আরও বেশি স্থিতিশীল এবং সহজেই স্কেল করতে পারে।

Two-Phase Commit এর ব্যবহারিক প্রয়োগ

এর সীমাবদ্ধতা সত্ত্বেও, 2PC এখনও বিভিন্ন পরিস্থিতিতে ব্যবহৃত হয় যেখানে শক্তিশালী কনসিস্টেন্সি একটি গুরুত্বপূর্ণ প্রয়োজনীয়তা। কিছু উদাহরণের মধ্যে রয়েছে:

• Banking Systems: অ্যাকাউন্টগুলির মধ্যে তহবিল স্থানান্তর করার জন্য প্রায়শই একটি distributed transaction প্রয়োজন হয় যাতে টাকা একটি অ্যাকাউন্ট থেকে ডেবিট করা হয় এবং অন্যটিতে অ্যাটমিকভাবে ক্রেডিট করা হয়। একটি ক্রস-বর্ডার পেমেন্ট সিস্টেম বিবেচনা করুন যেখানে প্রেরক ব্যাংক এবং প্রাপক ব্যাংক ভিন্ন সিস্টেমে রয়েছে। 2PC ব্যবহার করা যেতে পারে যাতে তহবিলগুলি সঠিকভাবে স্থানান্তরিত হয়, এমনকি যদি একটি ব্যাংক অস্থায়ী ব্যর্থতার সম্মুখীন হয়।
• Order Processing Systems: ই-কমার্স উদাহরণের মতো, 2PC অর্ডার প্লেসমেন্ট, ইনভেন্টরি আপডেট এবং পেমেন্ট প্রসেসিং অ্যাটমিকভাবে সম্পাদিত হয় তা নিশ্চিত করতে পারে।
• Resource Management Systems: একাধিক সিস্টেম জুড়ে রিসোর্স বরাদ্দ করা, যেমন ভার্চুয়াল মেশিন বা নেটওয়ার্ক ব্যান্ডউইথ, রিসোর্সগুলি সামঞ্জস্যপূর্ণভাবে বরাদ্দ করা হয় তা নিশ্চিত করার জন্য একটি distributed transaction প্রয়োজন হতে পারে।
• Database Replication: রেপ্লিকেটেড ডেটাবেসগুলির মধ্যে কনসিস্টেন্সি বজায় রাখা distributed transaction জড়িত করতে পারে, বিশেষ করে এমন পরিস্থিতিতে যেখানে ডেটা একাধিক রেপ্লিকাতে একই সাথে আপডেট করা হয়।

Two-Phase Commit বাস্তবায়ন

2PC বাস্তবায়নের জন্য বিভিন্ন কারণ বিবেচনা করা প্রয়োজন, যার মধ্যে রয়েছে:

• Transaction Coordinator: একটি উপযুক্ত transaction coordinator নির্বাচন করা অত্যন্ত গুরুত্বপূর্ণ। অনেক ডেটাবেস সিস্টেম বিল্ট-ইন transaction coordinator সরবরাহ করে, যখন অন্যান্য বিকল্পগুলির মধ্যে JTA (Java Transaction API) বা মেসেজ কিউতে distributed transaction coordinator এর মতো স্ট্যান্ডঅ্যালোন transaction manager অন্তর্ভুক্ত।
• Resource Managers: Resource managers 2PC সমর্থন করে তা নিশ্চিত করা অপরিহার্য। বেশিরভাগ আধুনিক ডেটাবেস সিস্টেম এবং মেসেজ কিউ 2PC এর জন্য সমর্থন প্রদান করে।
• Failure Handling: কোঅর্ডিনেটর বা পার্টিসিপেন্ট ব্যর্থতার প্রভাব কমাতে শক্তিশালী ব্যর্থতা হ্যান্ডলিং পদ্ধতি প্রয়োগ করা গুরুত্বপূর্ণ। এর মধ্যে transaction লগ ব্যবহার করা, timeout পদ্ধতি প্রয়োগ করা এবং ম্যানুয়াল হস্তক্ষেপের বিকল্প সরবরাহ করা অন্তর্ভুক্ত থাকতে পারে।
• Performance Tuning: 2PC এর কর্মক্ষমতা অপ্টিমাইজ করার জন্য লেনদেন টাইমআউট, নেটওয়ার্ক সেটিংস এবং ডেটাবেস কনফিগারেশনের মতো বিভিন্ন প্যারামিটারগুলির যত্ন সহকারে টিউনিং প্রয়োজন।
• Monitoring and Logging: Distributed transaction এর স্থিতি ট্র্যাক করতে এবং সম্ভাব্য সমস্যাগুলি সনাক্ত করতে ব্যাপক মনিটরিং এবং লগিং প্রয়োগ করা অপরিহার্য।

Distributed Transactions এর জন্য বৈশ্বিক বিবেচনা

একটি বৈশ্বিক পরিবেশে distributed transaction ডিজাইন এবং বাস্তবায়ন করার সময়, বেশ কয়েকটি অতিরিক্ত কারণ বিবেচনা করা প্রয়োজন:

• Network Latency: নেটওয়ার্ক ল্যাটেন্সি 2PC এর কর্মক্ষমতাকে উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে, বিশেষ করে ভৌগলিকভাবে distributed system-এ। নেটওয়ার্ক সংযোগগুলি অপ্টিমাইজ করা এবং ডেটা ক্যাশিংয়ের মতো কৌশলগুলি ব্যবহার করা ল্যাটেন্সির প্রভাব কমাতে সাহায্য করতে পারে।
• Time Zone Differences: টাইম জোন পার্থক্য লেনদেন প্রক্রিয়াকরণকে জটিল করে তুলতে পারে, বিশেষ করে টাইমস্ট্যাম্প এবং নির্ধারিত ইভেন্টগুলির সাথে কাজ করার সময়। একটি সামঞ্জস্যপূর্ণ টাইম জোন (যেমন, UTC) ব্যবহার করার সুপারিশ করা হয়।
• Data Localization: ডেটা স্থানীয়করণের প্রয়োজনীয়তা বিভিন্ন অঞ্চলে ডেটা সংরক্ষণ করার প্রয়োজন হতে পারে। এটি distributed transaction management কে আরও জটিল করে তুলতে পারে এবং ডেটা গোপনীয়তা নিয়মগুলির সাথে সম্মতি নিশ্চিত করার জন্য যত্নশীল পরিকল্পনার প্রয়োজন।
• Currency Conversion: একাধিক মুদ্রার সাথে জড়িত আর্থিক লেনদেনের সাথে কাজ করার সময়, নির্ভুলতা এবং নিয়ম মেনে চলার জন্য মুদ্রা রূপান্তর সাবধানে পরিচালনা করা প্রয়োজন।
• Regulatory Compliance: ডেটা গোপনীয়তা, নিরাপত্তা এবং আর্থিক লেনদেন সংক্রান্ত বিভিন্ন দেশের বিভিন্ন নিয়ম রয়েছে। distributed transaction ডিজাইন এবং বাস্তবায়ন করার সময় এই নিয়মগুলি মেনে চলা অপরিহার্য।

Conclusion

Distributed transaction এবং Two-Phase Commit (2PC) protocol হল শক্তিশালী এবং সামঞ্জস্যপূর্ণ distributed system তৈরির জন্য অপরিহার্য ধারণা। যদিও 2PC অ্যাটমিকিটি নিশ্চিত করার জন্য একটি সহজ এবং ব্যাপকভাবে গৃহীত সমাধান সরবরাহ করে, এর সীমাবদ্ধতাগুলি, বিশেষ করে ব্লকিং এবং সিঙ্গেল পয়েন্ট অফ ফেইলিউর সম্পর্কিত, Saga এবং ইভেনচুয়াল কনসিস্টেন্সির মতো বিকল্প পদ্ধতির যত্নশীল বিবেচনাকে আবশ্যক করে তোলে। আপনার নির্দিষ্ট অ্যাপ্লিকেশন প্রয়োজনের জন্য সঠিক পদ্ধতি নির্বাচন করার জন্য শক্তিশালী কনসিস্টেন্সি, প্রাপ্যতা এবং পারফরম্যান্সের মধ্যে ট্রেড-অফগুলি বোঝা গুরুত্বপূর্ণ। অধিকন্তু, একটি বৈশ্বিক পরিবেশে কাজ করার সময়, নেটওয়ার্ক ল্যাটেন্সি, টাইম জোন, ডেটা স্থানীয়করণ এবং নিয়ন্ত্রক সম্মতি সংক্রান্ত অতিরিক্ত বিষয়গুলি distributed transaction এর সাফল্য নিশ্চিত করার জন্য সমাধান করা আবশ্যক।