فحص الاتصال بخادم قواعد البيانات ليس بالسهولة التي يبدو عليها من وجهة نظر المبرمج المبتدئ (وأحياناً حتى الخبير). أول ما يخطر على بال المبرمج عندما يكتب قطعة برمجية لفحص الاتصال بخادم قواعد البيانات (Check DB Connection) هو فحص حالة خدمة قواعد البيانات على الجهاز الخادم من حيث كونها تعمل أم لا، وهو إذ يفكر بهذه الطريقة فإنه يفترض مخطئاً أن جهاز العميل على ما يرام من حيث توفر اتصاله بالشبكة في تلك اللحظة، ويفترض كذلك (وأيضاً مخطئاً) أن الجهاز الخادم يمكن الوصول إليه في تلك اللحظة. هذا ليس صحيحاً في كل الأوقات، وافتراض صحته في كل الأوقات يؤثر سلباً في سرعة وأداة تلك القطعة البرمجية.
الخطوة الأولى في أي قطعة برمجية لفحص الاتصال بخادم قواعد البيانات هي أولاً فحص حالة الشبكة في الجهاز العميل، إذا وجدت على ما يرام، ينتقل مباشرة إلى فحص الاتصال بجهاز الخادم وما إذا كان يمكن الوصول إليه أم لا. إذا وجد أيضاً أن الاتصال بالخادم يمكن تحقيقه، هنا فقط يبدأ بفحص خدمة قواعد البيانات على الجهاز الخادم.
هذا هو المنطق الصحيح، وهو الذي أعتمده في برامجي، لأن هذه الطريقة أسرع بكثير من الطريقة التقليدية، والسبب هو أنه في معظم الأحوال يكون فشل الاتصال بخادم قواعد البيانات ليس سببه غياب خدمة قواعد البيانات على الجهاز الخادم، بل فشل الشبكة على الجهاز العميل، أو أن الجهاز الخادم لا يمكن الوصول إليه أصلاً (في حين خدمة قواعد البيانات تعمل عليه على ما يرام)، وحيث أن فحص توفر الشبكة على الجهاز العميل، وفحص إمكانية الوصول إلى الجهاز الخادم هي إجراءات أسرع بكثير من إجراءات التأكد من عمل خدمة قواعد البيانات على الجهاز الخادم فإن أداء القطعة البرمجية الإجمالي يكون أفضل بكثير.
أخيراً، لا حاجة بي للقول أن طريقتي هذه لا فائدة منها في حالة ضمان توفر الشبكة على الجهاز العميل وضمان إمكانية الوصول للجهاز الخادم بنسبة 100% كل الوقت، غير أن هذا لا يتوافر في الواقع خصوصاً في دول العالم الثالث حيث تتردى فيها جودة وأداء تجهيزات الشبكات وجودة الربط بين المحطات.
ليست هناك تعليقات:
إرسال تعليق