يعتبر الـ 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

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

Optimistic Locking In a Nutshell

ايه هو الـ Pessimistic Locking ؟

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

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

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

Pessimistic Locking In a Nutshell
Pessimistic Locking In a Nutshell

وفيه أنواع مختلفة من الـ Pessimistic Locking:

زي الـ Exclusive Locks ودي غرضها انها تمنع كل العمليات من انها توصل للـ Row أو الـ Record اللي معمول عليه Locking

وفيه برضو الـ Shared Locks ودي بتسمح فقط لعمليات الـ Read انها تقرا البيانات عادي جدًا حتى لو فيه عملية حالية بتعمل على البيانات دي Update ولكن بتمنع عمليات الـ Write / Update التانية تماما.

💡
فالخلاصة أن الـ Pessimistic Locking بيشتغل على فرضية اني هعمل احتياطاتي وخايف ان يحصل Conflicts وبالتالي انا هقفل على الـ Row / Record اللي شغال عليه وخلاص عشان احمي نفسي.

امتة نستخدم الـ Pessimistic Locking ؟

يفضل استخدامه في النظم اللي بطبيعتها تضمن حدوث Concurrent Updates بشكل متكرر , وبتحتاج لتنسيق دقيق جدا بين العمليات دي عشان نمنع حدوث أي Conflicts ممكن تؤدي لخطأ في البيانات. وعلى الرغم من ده الا إن استعمال الـ Pessimistic Locking ممكن يؤدي لبطء في أداء النظام لو تم استعماله بشكل غير فعال , وعشان كده اختيارنا للطريقة المناسبة بيتضمن فهمنا كويس جدًا بالنظام والمتطلبات بتاعتنا.

وفيه كتير من قواعد البيانات زي الـ MySQL بتختار اصلا الآلية دي بشكل افتراضي لو كان الـ Isolation Level هو الـSerializability.

مميزات الـ Pessimistic Locking  ؟

  1. أدق وأضمن أن البيانات تكون Consistent مع بعضها.
  2. ممكن يتم تطبيقه في النظم اللي بتعمل Concurrent Updates بشكل كتير ومتكرر بشكل سهل ومش متطلب لأي تعقيدات خارجية واضافية .

عيوب الـ Pessimistic Locking ؟

  1. ممكن يؤدي كثرة استعماله لبطء في النظام ، خاصة لو كان فيه Locks كتيرة ولفترات زمنية طويلة
  2. ممكن يؤدي لتأخير في الاستجابة لعمليات الـ Read / Write وده ممكن يؤثر على أداء التطبيق ككل

ملاحظات ختامية

💡
بشكل عام، ممكن نقول أن Pessimistic Locking يعتبر مناسبًا للـ Systems التي بتتطلب Concurrent Updates بشكل متكرر ومحتاجة أن البيانات تكون Consistent مع بعضها بشكل دقيق!