الـ Locks و Two-Phase Locking

1. Shared و Exclusive

فيه نوعين أساسيين:

• Shared Lock (S): للقراية. كذا ترانزاكشن ممكن يمسكوا S على نفس العنصر في نفس الوقت، لأن القراية مش بتأثر على حد.
• Exclusive Lock (X): للكتابة. ترانزاكشن واحدة بس تمسكه، ومحدش تاني يقدر يقرا (بـ Lock) ولا يكتب.

ده اسمه Compatibility Matrix، وكل أنواع الـ Locks اللي جاية ليها جدول زيه.

كذا حد يقرا مع بعض، بس اللي بيكتب لازم يبقى لوحده.

2. القفل لوحده مش كفاية

خلّينا نجرب قاعدة بسيطة: “اقفل العنصر قبل ما تستخدمه، وافتحه أول ما تخلص منه”.

كل عملية اتعملت وهي ماسكة Lock صح، ومع ذلك T2 شافت A بعد الخصم و B قبل الإضافة: الإجمالي ناقص 100. السبب إن T1 فكت A وبعدين رجعت تقفل حاجة جديدة، فT2 دخلت في النص.

المشكلة مش في إنك تقفل، المشكلة في إنك تفك وبعدين ترجع تقفل.

3. Two-Phase Locking (2PL)

اللحظة اللي الترانزاكشن خدت فيها آخر Lock اسمها Lock Point.

النظرية (Eswaran وزمايله، 1976): لو كل الترانزاكشنز ماشية على 2PL، أي Schedule هيطلع Conflict Serializable، والترتيب Serial المكافئ هو ترتيب الـ Lock Points.

ليه؟ فكرة الإثبات: لو فيه سهم T1 → T2 في الـ Precedence Graph، يبقى T2 استنت Lock كان مع T1، يعني T1 فكت قبل ما T2 تاخد، يعني الـ Lock Point بتاع T1 قبل بتاع T2. لو فيه Cycle، يبقى T1 قبل T2 قبل … قبل T1، يعني T1 قبل نفسها، وده مستحيل.

في مثال التحويل: T1 تحت 2PL لازم تاخد X(A) و X(B) الاتنين قبل ما تفك أي واحد. فT2 هتشوف يا الاتنين قبل التحويل، يا الاتنين بعده.

2PL = خد كل اللي محتاجه قبل ما تسيب أي حاجة. ده كفاية يضمن Serializability.

4. Strict و Rigorous 2PL

الـ 2PL الأساسي بيسمح تفك Locks قبل الـ COMMIT (في الـ Shrinking Phase). المشكلة: لو فكيت X Lock على صف كتبته، حد تاني يقرا قيمتك، وبعدين إنت تعمل ABORT، يبقى Cascading Abort (شفناه في الدرس اللي فات).

كل الداتابيز اللي بتستخدم Locks بتعمل Strict أو Rigorous. وده ليه إنت عمرك ما شفت أمر UNLOCK ROW في SQL: الـ Row Locks بتتفك لوحدها في الـ COMMIT أو الـ ROLLBACK.

وده سبب أهم قاعدة عملية في الموضوع كله: خلّي الترانزاكشن قصيرة. كل ثانية الترانزاكشن مفتوحة فيها، كل الـ Locks اللي خدتها ماسكة الناس مستنية.

في الداتابيز الحقيقية، Lock الكتابة بيفضل لحد الـ COMMIT. فطول الترانزاكشن = طول الاستنا عند كل اللي وراك.

5. حجم القفل والـ Intention Locks

تقفل إيه بالظبط؟ صف؟ صفحة؟ جدول؟

الداتابيز بتدعم أكتر من حجم مع بعض (Multiple Granularity Locking). بس فيه مشكلة: ترانزاكشن عايزة تقفل الجدول كله X. إزاي تعرف إن مفيش حد ماسك صف واحد جواه من غير ما تلف على مليون صف؟

الحل: Intention Locks. قبل ما تقفل صف، بتحط “نية” على الجدول.

لاحظ إن IX مع IX متوافقين: ترانزاكشنين بيكتبوا صفوف مختلفة في نفس الجدول مايستنوش بعض على مستوى الجدول. والخناقة الحقيقية بتبقى على مستوى الصف.

في InnoDB: أي SELECT ... FOR SHARE بياخد IS على الجدول، وأي UPDATE أو FOR UPDATE بياخد IX، وبعدين Lock على الصف. و LOCK TABLES ... WRITE بياخد X على الجدول. وفي SQL Server فيه كمان Lock Escalation: لو ترانزاكشن خدت آلاف Row Locks، الداتابيز بتحولهم لـ Table Lock واحد. InnoDB و PostgreSQL مش بيعملوا كده.

6. Phantoms: إزاي تقفل صف مش موجود؟

SELECT * FROM employees WHERE dept = 'IT' FOR UPDATE بيقفل الـ 3 صفوف الموجودين. بس حد يعمل INSERT لموظف رابع في IT، وده صف جديد مفيش عليه Lock. فالـ Phantom لسه بيعدّي حتى مع 2PL على الصفوف.

الحل النظري: Predicate Lock، يعني تقفل الشرط نفسه dept = 'IT'، وأي INSERT يطابق الشرط يستنى. بس التأكد إن شرطين بيتقاطعوا مكلف جداً. فالداتابيز بتعمل حل عملي: تقفل المسافات في الـ Index.

InnoDB عنده 4 أنواع Row Locks:

في REPEATABLE READ، أي Locking Read أو UPDATE أو DELETE بشرط Range بياخد Next-Key Locks على كل اللي مسحه في الـ Index، فمحدش يقدر يحط صف جديد في النطاق ده.

وده بيوضح نقطة مهمة: الـ Index بيحدد حجم القفل. شرط على عمود من غير Index = Full Scan = Locks على كل صف عدّى عليه. وده سبب قصة “UPDATE واحد وقّف الموقع كله” في موضوع الـ Index.

PostgreSQL بيحل الـ Phantoms بطريقة مختلفة خالص: الـ Snapshot بتخلّي القراية مش شايفة الصفوف الجديدة، وفي SERIALIZABLE بيستخدم SIREAD Locks (Predicate Locks مش بتمنع حد، بس بتتابع التعارضات). ده في درس SSI.

الداتابيز مش بتقفل الشرط، بتقفل المكان في الـ Index اللي الصفوف المطابقة للشرط ممكن تتحط فيه. علشان كده الـ Index الصح بيصغّر الـ Lock.

7. الـ Row Locks في SQL

PostgreSQL عنده 4 مستويات لأن الـ UPDATE العادي اللي مش بيغيّر الـ Primary Key بياخد FOR NO KEY UPDATE بس، والـ Foreign Key check من جدول تاني بياخد FOR KEY SHARE. والاتنين دول متوافقين. فتعديل سعر منتج مش بيوقف إضافة أوردر بيشاور على المنتج ده.

-- حجز كرسي: لو حد ماسكه، قول للمستخدم فوراً بدل ما يستنى
SELECT * FROM seats WHERE id = 42 FOR UPDATE NOWAIT;
-- ERROR: could not obtain lock on row in relation "seats"   (PostgreSQL)
-- ERROR 3572: Statement aborted because lock(s) could not be acquired immediately and NOWAIT is set (MySQL)

-- Worker بياخد شغل من طابور: كل Worker ياخد صفوف مختلفة من غير ما يستنوا بعض
SELECT * FROM jobs
WHERE status = 'pending'
ORDER BY id
LIMIT 10
FOR UPDATE SKIP LOCKED;

8. أسئلة الإنترفيو