المعاملات وإدارة الذاكرة المؤقتة

هناك تجربة يمر بها كل مطوّر JPA يومًا ما، ولا تُنسى: تعدّل كيانًا دون أن تستدعي أي دالة حفظ، ثم تكتشف أن قاعدة البيانات قد حُدِّثت فعلًا. وفي المقابل، تستدعي save() صراحةً فتجد أن شيئًا لم يتغير. السبب في الحالتين واحد: أنت لا تعرف ما إذا كان الكائن الذي تتعامل معه مُدارًا من قِبل سياق الاستمرارية (contexte de persistance).

سياق الاستمرارية هو قلب عمل JPA. إنه سجل في الذاكرة، محدود بنطاق المعاملة، يحتوي على جميع الكيانات التي حُمِّلت أو أُنشئت أثناء تلك المعاملة. ويحتفظ Hibernate فيه أيضًا بلقطة لحالتها لحظة التحميل. وعند نهاية المعاملة يقارن الكائنات بلقطاتها، ويُصدر UPDATE لكل اختلاف يجده. هذه الآلية، المسماة فحص التغييرات (dirty checking)، هي ما يفسّر كون استدعاء بسيط لـ setPrix() كافيًا للكتابة في قاعدة البيانات.

لهذه الأناقة ثمن: لحظة إرسال SQL لم تعد يحددها كودك، بل Hibernate. فالكتابات تتجمّع وتُرسل في اللحظة الأخيرة، بترتيب يختاره Hibernate. وفهم هذا التأجيل هو ما يفصل بين المطوّر الذي يخضع لـ @Transactional والمطوّر الذي يتحكم فيه.

يتناول هذا الدرس بعد ذلك التزامن — مستخدمان يعدّلان السطر نفسه — والذاكرة المؤقتة، وهي الامتداد المباشر لسياق الاستمرارية.