ذاكرة التخزين المؤقت للاستعلام السباتية - للكائنات ليست في ذاكرة التخزين المؤقت للمستوى الثاني - محفوفة بالمخاطر؟ مفيد؟ سوء الممارسة؟

Question

متعلق بهذا سؤال

فرضية:

هذه هي افتراضاتي ، بناءً على قراءتي وتجربتي وفهمها ، قد تكون مخطئة ، إذا كانت كذلك ، يرجى التعليق وسأقوم بتحرير السؤال.

• ذاكرة التخزين المؤقت الاستعلام جيدة في الغالب مع ذاكرة التخزين المؤقت من المستوى الثاني
• استفسار ذاكرة التخزين المؤقت لنتائج المعرفات للاستعلامات + المعلمات
• تخزين ذاكرة التخزين المؤقت للاستعلام محفوف بالمخاطر إذا تم تغيير قاعدة البيانات ، ولم ينعكس على ذاكرة التخزين المؤقت

سؤال:

لدي كائن ليس في ذاكرة التخزين المؤقت من المستوى الثاني. نظرًا لبعض البرمجة السيئة أو القيود الأخرى ، يتم استدعاء الكود الذي يحمل الكائن عدة وقت في جلسة السبات نفسها. تستخدم Retriven

 hibernateTemplate.find("from Foo f where f.bar > ?", bar);

قبل إضافة ذاكرة التخزين المؤقت للاستعلام ، إذا تم استدعاء الرمز أعلاه N Times داخل جلسة السبات نفسها ، كانت هناك ضربات n في قاعدة البيانات

ثم أردت أن أرى ما يحدث إذا أضفت ذاكرة التخزين المؤقت للاستعلام:

 Query query = session.createQuery("from Foo f where f.bar > ?");
 query.setCacheable(true);
 query.setParameter(bar);
 query.list();

عندما أضفت ذاكرة التخزين المؤقت للاستعلام ، لاحظت أنه خلال الجلسة نفسها ، لم يعد Hibernate يضغط على قاعدة البيانات n بعد الآن ، مرة واحدة فقط لكل جلسة.

1. لذا فإن افتراضي الأول هو أن السبات يبحث أولاً في ذاكرة التخزين المؤقت للجلسة ، ثم في ذاكرة التخزين المؤقت للمستوى الثاني. هل هذا الافتراض صحيح؟
2. أفترض أيضًا أنه إذا كان الكائن (Foo) وهو ليس في ذاكرة التخزين المؤقت للمستوى الثاني ، تم تغييره في قاعدة البيانات ، ثم الاستعلام عن ذاكرة التخزين المؤقت ، الذي يتم تحديده في الجلسة المتقاطعة ، ستعيد المعرفات الخاطئة ، وبالتالي الكائنات الخاطئة. هل هذا صحيح؟
3. هل من الآمن بعد ذلك القول بأن استخدام ذاكرة التخزين المؤقت للاستعلام للاستعلامات التي تتضمن معلومات غير قابلة للتغيير حتى بالنسبة للكائنات غير المخبأة 2L ، هل ممارسة جيدة؟ (على سبيل المثال ، استعلام يحتوي على الفقرة حيث يحتوي البند على شرط سيعيد دائمًا نفس النتائج ، على سبيل المثال "حدد p.ser_num حيث p.id =؟" عندما لا يتغير الأزواج Ser_num و ID بمجرد إنشاء)

بالمناسبة ، في الصلة سؤال يُزعم أن ذاكرة التخزين المؤقت للاستعلام لا تعمل على نطاق ذاكرة التخزين المؤقت للجلسة. هل أفتقد هذا الادعاء أم أي شيء آخر؟

Answer 1

ذاكرة التخزين المؤقت للاستعلام هي نوع معين من ذاكرة التخزين المؤقت من المستوى الثاني. ما تشير إليه باسم ذاكرة التخزين المؤقت من المستوى الثاني ، أفضل أن أسمي "ذاكرة التخزين المؤقت للكائن".

تعليقات على افتراضاتك:

• يعد عملية التخزين المؤقت للاستعلام جيدة في الغالب مع ذاكرة التخزين المؤقت من المستوى الثاني (AKA Object Cache).

يحمل ذاكرة التخزين المؤقت للاستعلام فقط النتائج الأولية للاستعلامات كمفاتيح أساسية ، في الكلام السباتي ، معرف. لا يحمل الكائنات المائية الفعلية. هذا أمر منطقي كما هو الحال عند تنفيذ استعلام باستخدام JDBC ، فإنه يمنحك فعليًا فقط كائنات رطبة (مكتظة بالسكان) أثناء تكرارك على مجموعة النتائج. البيان غير صحيح بالضرورة. إذا كان الاستعلام معقدًا للغاية ، وبالتالي يستغرق وقتًا طويلاً للغاية للتشغيل ، باستخدام ذاكرة التخزين المؤقت للاستعلام ، فسوف توفر ذلك الوقت. لن تقوم ، باستخدام ذاكرة التخزين المؤقت للاستعلام ، احفظ الوقت الذي يستغرقه تحميل الكائنات من قاعدة البيانات.

• تخزين ذاكرة التخزين المؤقت للاستعلام محفوف بالمخاطر إذا تم تغيير قاعدة البيانات ، ولم ينعكس على ذاكرة التخزين المؤقت

هذا صحيح ، ولكنه ليس فريدًا من خلال عملية التخزين المؤقت للاستعلام ، وينطبق الشيء نفسه على ما تصفه ذاكرة التخزين المؤقت من المستوى الثاني ، ولكن ما يسمى عادةً ذاكرة التخزين المؤقت للكائن.

لذا فإن افتراضي الأول هو أن السبات يبحث أولاً في ذاكرة التخزين المؤقت للجلسة ، ثم في ذاكرة التخزين المؤقت للمستوى الثاني. هل هذا الافتراض صحيح؟

نعم ، عند تحميل الكائنات هذا هو السلوك.

أفترض أيضًا أنه إذا تم تغيير الكائن (FOO) الذي لم يكن في ذاكرة التخزين المؤقت من المستوى الثاني ، في قاعدة البيانات ، فسيقوم بالتذاكر ذاكرة التخزين المؤقت للاستعلام ، حيث يتم تحديد موقع Scoped Scoped ، إلى المعرفات الخاطئة ، وبالتالي الكائنات الخاطئة. هل هذا صحيح؟

نعم ، سيتأثر كل من ذاكرة التخزين المؤقت للكائن وذاكرة التخزين المؤقت للاستعلام. هذا هو مجرد قلق إذا تم تغيير قاعدة البيانات دون الذهاب عبر السبات. يمكنك التخفيف من تأثير هذا عن طريق تعيين مهلة ذاكرة التخزين المؤقت للاستعلام.

هل من الآمن بعد ذلك القول بأن استخدام ذاكرة التخزين المؤقت للاستعلام للاستعلامات التي تتضمن معلومات غير قابلة للتغيير حتى بالنسبة للكائنات غير المخبأة 2L ، هل ممارسة جيدة؟ (على سبيل المثال ، استعلام يحتوي على الفقرة حيث يحتوي البند على شرط سيعيد دائمًا نفس النتائج ، على سبيل المثال "حدد p.ser_num حيث p.id =؟" عندما لا يتغير الأزواج Ser_num و ID بمجرد إنشاء)

لهذا النوع من الكائنات ، لا يوجد سبب لعدم استخدام كل من ذاكرة التخزين المؤقت للكائن وذاكرة التخزين المؤقت للاستعلام.

ونعم ، لا تعمل ذاكرة التخزين المؤقت للاستعلام على مستوى الجلسة الملقب ذاكرة التخزين المؤقت المستوى 1. وبالتالي فإن السبب في تنفيذ الاستعلام مرة أخرى ، فإنه يضرب قاعدة البيانات مرة أخرى. لن يضع النتيجة (مجموعة المعرف) لاستعلام في ذاكرة التخزين المؤقت للجلسة.

Answer 2

الافتراضات فقط:

حسب هذا مقالة - سلعة من وثائق السبات:

CACHE QUERY] ينشئ منطقتين جديدتين لذاكرة التخزين المؤقت: واحدة من مجموعات نتائج الاستعلام المخبأة (org.hibernate.cache.standardquerycache) ، الطوابع الزمنية الأخرى المحتجزة من أحدث التحديثات إلى الجداول القابلة للاستعلام (org.hibernate.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache.cache).

أفترض أن هذا يعني أنه عندما يكون الطابع الزمني للجدول القابل للاستعلام أحدث من مجموعة النتائج - فإنه سيؤدي إلى الاقتراب من DB في الدعوة التالية لهذا الاستعلام ، وهذا ما يبقي ذاكرة التخزين المؤقت للاستعلام في بعض الجوانب.

لكن جملتين في وقت لاحق في نفس الفقرة من الوثائق التي تقول:

يجب دائمًا استخدام ذاكرة التخزين المؤقت للاستعلام بالاقتران مع ذاكرة التخزين المؤقت من المستوى الثاني.

مرة أخرى ، افتراضي هو أن هذه هي الطريقة الوحيدة التي يمكن أن تكون بها السباتات على التغييرات في قاعدة البيانات التي يتم إجراؤها من جلسة المستخدم المحددة هذا

Answer 3

لسؤالك رقم 3 ، لا أعتقد أنك تريد استخدام ذاكرة التخزين المؤقت للاستعلام عندما لا يتم تخزين الكائنات مؤقتًا. سينتهي بك الأمر إلى جميع المعرفات الأساسية ولكن سيتعين عليه ضرب قاعدة البيانات مرة واحدة لكل مفتاح لاسترداد الكائنات التي قد تكون أبطأ من تشغيل الاستعلام دون التخزين المؤقت على الإطلاق. اعتبارًا من 3.3 على أي حال ، ربما في الإصدارات الأحدث ، يمسك الكائنات المفقودة باستخدام أقل استعلامات ، على سبيل المثال حيث المعرف في (: ID1 ،: ID2 ، ...).