VPN ڈاؤن ہونے کے بعد SQL Server سے Oracle تک لوڈ کی بحالی
VPN ڈاؤن ہونے سے کال کرنے والا یقینی نہیں رہتا کہ Oracle میں commit ہوا یا نہیں۔ ایک پائیدار بیچ ID نکاسی، اطلاق اور مصالحت کے سوالات کا ایک ایک کرکے جواب دینے دیتا ہے۔
VPN ڈاؤن ہونے پر ڈیٹا بیس کے درمیان منتقلی مر جاتی ہے، اور «اسے دوبارہ چلائیں» کوئی بحالی منصوبہ نہیں ہے۔ ماخذ سے نکاسی مکمل ہو سکتی ہے، ہدف پہلے ہی commit کر چکا ہو سکتا ہے، یا جواب واپسی کے راستے میں ہی گم ہو گیا ہو۔ ان تین حالتوں کے لیے مختلف اقدامات درکار ہیں، اور صرف «خرابی» جاننے والا کلائنٹ انہیں الگ نہیں کر سکتا۔
حل معماری ہے: ہر رن کو ایک پائیدار بیچ شناخت دیں، اور کلائنٹ کو اندازہ لگانے دینے کے بجائے ڈیٹا بیس کو سوالات کا جواب دینے دیں۔
ڈیٹا بیس اصل میں کیا ضمانت دیتا ہے
SQL Server اور Oracle دونوں لین دین کے اندر جوہریت دیتے ہیں۔ دونوں کے درمیان جوہریت کوئی نہیں دیتا۔ گمشدہ کنکشن ڈیٹا بیس کو خراب نہیں کرتا، اور دستی رول بیک پر مجبور بھی نہیں کرتا، کیونکہ سرور آپ کے بغیر اپنا لین دین خود حل کرتا ہے۔ جو ٹوٹتا ہے وہ نتیجے کے بارے میں کال کرنے والے کا علم ہے۔
الگ الگ commit کا مطلب الگ الگ commit ہے۔ دونوں کنکشن لے جانے والا VPN دو commit کو ایک کام کی اکائی میں ضم نہیں کرتا۔
وہ commit جس کے بارے میں آپ نے کبھی نہیں سنا
ناکامی کا ایک طریقہ سادہ لوح دوبارہ کوشش کے منطق کو سزا دیتا ہے: سرور commit کرتا ہے، اور تصدیق کبھی کال کرنے والے تک نہیں پہنچتی۔ Oracle اسے نامعلوم نتیجے کا مسئلہ قرار دیتا ہے اور اس کے لیے لین دین کی دستاویزات میں Transaction Guard فراہم کرتا ہے۔ مواصلاتی خرابی اس بات کا ثبوت نہیں کہ بھیجا گیا commit ناکام ہوا، اور اسے ثبوت سمجھنا ہی وہ راستہ ہے جس سے بیچ دو بار پوسٹ ہوتا ہے۔ یہ فرق دوبارہ کوشش کے راستے پر سب سے زیادہ اہم ہے، جہاں آپریٹر کے پاس صرف خرابی کا پیغام ہوتا ہے اور عمل کے لیے کوئی دوسرا اشارہ نہیں۔
اسی لیے بحالی کے مرحلے کو نتیجہ خرابی کے متن سے اندازہ لگانے کے بجائے ہدف سے پڑھنا چاہیے۔
منتقلی کو بیچ شناخت دیں
ہر رن کو ناقابل تبدیل بیچ ID ملتی ہے، اور ہدف ریکارڈ کرتا ہے کہ اس ID کے ساتھ اس نے کیا کیا۔ زندگی کا چکر چار مراحل پر مشتمل ہے، اور بیچنے والا کوئی بھی ہو یہ ایک جیسا دکھائی دیتا ہے:
- نکاسی ریکارڈ شدہ اسکیما اور حد کے ساتھ شناخت شدہ، ناقابل تبدیل ماخذ بیچ۔
- منتقل کریں اسے ہدف کے اسٹیجنگ علاقے میں، اور تیار قرار دینے سے پہلے نامکمل یا متضاد مواد کا پتہ لگائیں۔
- لاگو کریں ہدف کے اپنے یکسانیت یا تالے کے قواعد کے تحت، اور اسی مقامی لین دین میں تکمیل ریکارڈ کریں۔
- مصالحت کریں پائیدار نتیجے کی معاون پروٹوکول کے ذریعے، تصدیق یا دوبارہ کوشش سے پہلے۔
دوبارہ کوششیں وہی ID دوبارہ استعمال کرتی ہیں۔ ہر کوشش کے لیے نئی ID اس ڈپلیکیٹ روک تھام کو بے کار کرتی ہے جو آپ نے ابھی بنائی، جو تب تک واضح لگتا ہے جب تک دوبارہ کوشش کا ریپر خودبخود ایک نہ بنا دے۔
ID آپ کو بعد میں مصالحت کے لیے کچھ دیتی ہے، کلائنٹ کا عمل بہت پہلے ختم ہونے کے بعد بھی۔
بیچ کا دعویٰ کریں، پھر لاگو کریں
اطلاق کے مرحلے کو بیچ ID کا دعویٰ کرنا چاہیے، کاروباری تبدیلیاں کرنی چاہئیں، اور تکمیل ایک مقامی لین دین میں ریکارڈ کرنی چاہیے۔ جانچ اور اندراج کو الگ الگ بیانات کے طور پر کرنا اس دوڑ کو واپس لاتا ہے جسے آپ ہٹانا چاہتے تھے۔ اگر دو کارکن مقابلہ کریں تو ٹھیک ایک دعویٰ جیتتا ہے اور دوسرے کو بتا دیا جاتا ہے۔
تکمیل کا ریکارڈ نہ ہونا اس بات کا ثبوت نہیں کہ جاری لین دین کبھی commit نہیں کرے گا۔ دعوے کو مقابلہ کرنے والی کوششوں کو ترتیب دینا چاہیے، یا پروٹوکول کو کسی بھی فیصلے سے پہلے پائیدار نتیجہ پڑھنا چاہیے۔
اس ترتیب کے لیے ایپلیکیشن کوڈ میں جانچ-پھر-دہرائیں لوپ کے بجائے ڈیٹا بیس کی معاون طریقہ کار استعمال کریں۔
ڈیزائن ابھی کیا وعدہ نہیں کر سکتا
اسٹیجنگ کام کو دوبارہ شروع کرنے کے قابل بناتی ہے اور ایک طویل سیشن پر انحصار کم کرتی ہے۔ یہ SQL Server، Oracle اور کام کے کسی بھی بیرونی ضمنی اثر پر ایک ہی جوہری commit نہیں بناتی۔ اگر کاروبار کو واقعی اس کی ضرورت ہو، تو معاون تقسیم شدہ لین دین یا مصالحت کا عمل ڈیزائن کریں اور اہل قرار دیں، بشمول یہ کہ غیر یقینی نتیجے والا کام کس کا ہے۔ اس سے کمزور کوئی بھی چیز منتقلی کوڈ میں نہیں، مصالحت کی رن بک میں آتی ہے۔
تین جگہوں پر رکاوٹ قبول کریں: منتقلی کے دوران، اطلاق کے دوران، اور commit کے بعد لیکن تصدیق سے پہلے۔ پھر کلائنٹ کے پیغام کے بجائے کاروباری نتیجہ جانچیں، اور بیچ لیجر کو بتانے دیں کہ کام نامکمل ہے، commit ہو چکا ہے، یا ابھی حل نہیں ہوا۔