معاملات قواعد البيانات والتحديثات المتزامنة
· PoolByte Technology
إذا تم إنشاء سجل طلب ولكن لم يتم إنشاء صفوفه، أو إذا أدى إجراء المستخدم إلى ترك سجلين منفصلين متعارضين، فإن المشكلة ليست دائمًا استعلامًا بطيئًا. في بعض الأحيان، يقوم التطبيق بمعالجة التغييرات التي يجب إكمالها معًا كوظائف منفصلة. تُستخدم معاملات قاعدة البيانات، أي بنية المعاملات، لتحديد حد الاتساق هذا.
تحدد قاعدة العمل حد المعاملة
يمكن أن تكون مسودة الفاتورة وعناصرها جزءًا من نفس الوظيفة. إما أنه يجب إكمال السجلات المطلوبة معًا، أو يجب ألا تتوفر مسودة غير مكتملة. يصف مستند MySQL COMMIT وROLLBACK سلوك الالتزام بالتغييرات والتراجع عنها. يتم أيضًا التحقق من مدى ملاءمة محرك التخزين والأوامر المستخدمة لهذا السلوك.
بدء المعاملة لا يحل كافة الأخطاء. لا يمكن لقاعدة البيانات المحلية التراجع عن العملية التي تقوم بها خدمة خارجية. على سبيل المثال، يختلف حد الإرسال إلى خدمة المستندات وتحديث السجل المحلي. يجب أن يتتبع التطبيق هاتين النتيجتين مع حالات منفصلة؛ لا ينبغي تغطية عدم اليقين لدى أحدهما من خلال ظهور نجاح الآخر.
إذا قام مستخدمان بتغيير نفس السجل
قد يقوم أحد أعضاء الفريق بتحرير ميزانية المشروع بينما يحتفظ الآخر بنفس الشاشة القديمة مفتوحة. يلزم وجود حقل إصدار أو أسلوب قفل مناسب لمنع آخر كاتب من الكتابة فوق التغيير الآخر بصمت. باستخدام التحكم المتفائل في التزامن، قد يطلب التطبيق إعادة التقييم عن طريق التحقق مما إذا كان السجل قد تغير منذ أن قرأه المستخدم.
اجعل النطاق قصيرًا عندما يكون قفل الصف مطلوبًا. وصف قراءة قفل InnoDB يوضح الفرق بين القراءة العادية وقراءة القفل. قد يؤدي انتظار استجابة من المستخدم أو تقديم طلب شبكة طويل ضمن عملية مقفلة إلى انتظار العمليات الأخرى. يجب أن يكون واضحًا ما الذي يحميه التصميم وإلى متى.
كيف يتعامل التطبيق مع الجمود (Deadlock)؟
يمكن أن يحدث انتظار متبادل عندما تقوم عمليتان بتأمين الموارد بترتيب مختلف. إن الوصول إلى الموارد بترتيب متسق وإبقاء المعاملات قصيرة يقلل من هذا الاحتمال. ومع ذلك، قد يحتاج التطبيق إلى التعرف على خطأ قاعدة البيانات ذي الصلة وإعادة المحاولة ضمن الحدود الآمنة. تكرار كل خطأ إلى أجل غير مسمى ليس حلا.
ضع في اعتبارك التأثيرات الخارجية لإعادة محاولة المهمة. قد يتم إرسال إعلامين إلى المستخدم أو قد يحدث نفس الطلب الخارجي مرة أخرى، على الرغم من وجود سجل واحد فقط في قاعدة البيانات. إن تتبع التغييرات المحلية والتسليم الخارجي للعمل بشكل منفصل يوضح ما يجب تكراره في حالة حدوث أخطاء. إن مجرد كتابة "فشل" في السجل لا يكفي للمراجعة؛ يعد معرف الوظيفة وانتقال الحالة أكثر فائدة.
اختبار حقيقي للاتساق
- افحص ما إذا كان قد حدث خطأ في منتصف المهمة وبقيت أية سجلات جزئية.
- قم بتحديث نفس السجل في وقت واحد من خلال اتصالين منفصلين.
- تحقق من حد الانتظار وإعادة المحاولة.
- تأكد من أن النتيجة المقروءة بعد العملية الناجحة تتوافق مع قاعدة العمل.
- معرفة ما إذا كان السجل المحلي يظل مفهومًا عندما لا تستجيب الخدمة الخارجية.
تحسين الفهرس يمكن أن يساعد في تحسين الوقت؛ يحدد تصميم المعاملة الشروط التي سيتم بموجبها اعتبار السجلات صحيحة. لكي لا يكون التطبيق سريعًا فحسب، بل متسقًا أيضًا في الاستخدام المتزامن، يجب تقييم مشكلتين بشكل منفصل.