Pessimistic Locking In a Nutshell

يعتبر الـ Locking من أهم الآليات اللي بنعتمد عليها في الـ Databases بشكل أساسي عشان نتحكم في الـ Concurrent Access للبيانات من خلال أكثر من Transactions، فلو كان هناك عدد من الـ Transactions بيحاول يوصل للبيانات دي في نفس الوقت فأكيد هيحصل نتيجة لده تضارب بنسميه Conflicts.

💡

نقدر نتخيل الـ Locking كأنه زي القفل اللي بنقفل بيه على أي حاجة عشان نمنع أي حد من الوصول ليها. فالـ Databases أحيانًا بتحط قفل على الـ Row أو الـ Record لما يكون فيه Transaction شغال عليه عشان تمنع أي حد من الوصول للـ Row ده, اكنه دخل (الحمام وقفل وراه الباب) ..

طب هو ليه اصلا بنحتاج للـ Locking ؟

احنا بنحتاج للـ Locking لإنه بيقدملنا فوايد مهمة زي الـ Data Integrity & Data Consistency ودول من أهم الفوايد اللي بنحصل عليها من الـ Locking .. لإنه من غير Locking ممكن Two Concurrent Transactions يغيروا في قيمة الـ Column الواحد في نفس الوقت وده يسبب مشاكل كتير.

وعلى الرغم من فوايد الـ Locking الا انه بيجي مع تحديات كبيرة وتعقيدات في التعامل معاه، فلازم نكون فاهمينه عشان نقدر نتعامل معاه بشكل فعال.

فيه نوعين من الـ Locking وهم الـ Optimistic Locking والـ Pessimistic Locking بس احنا هنتكلم النهاردة عن الـ Pessimistic. وده لاننا اتكلمنا قبل كده عن الـ Optimistic Locking

ايه هو الـ Pessimistic Locking ؟

الـ Pessimistic Locking جاي من اسمه انه شخص متشائم، بيعمل حسابه دايما على أسوء الظروف وبناء عليه بيفكر لقدام وبياخد احتياطه مسبقا.

الـ Pessimistic Locking في قواعد البيانات بيمنع الـ Conflicts الناتجة من الـ Concurrent Updates واللي بتحصل بشكل Frequent أو متكرر. فلما بنيجي نعمل عملية تحديث لـ Row أو Record معين، فالـPessimistic Locking بتحط قفل على الـRow أو الـRecord ده عشان تمنع عمليات الـ Updates التانية من انها توصل لنفس الـ Row أو الـ Record في نفس الوقت.

ممكن نتخيل أن القفل ده عبارة عن اشارة حصرية فقط لعملية الـ Update الحالية , وبالتالي مش ممكن لأي عملية تانية انها توصل لنفس البيانات اللي شغالين عليها وده لانها بتكون مقفول عليها بالقفل لحد ما العملية الحالية تنتهي.