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

Question

يحتوي تطبيق Java الخاص بنا على حوالي 100 فئة تم تعيينها على قاعدة بيانات (SQL Server أو MySQL). نحن نستخدم Hibernate كـ ORM (مع ملفات رسم الخرائط XML).

نحدد FOREIGN KEY القيود في مخطط قاعدة البيانات لدينا. معظم لدينا FOREIGN KEY تحدد القيود أيضًا ON DELETE CASCADE.

لقد بدأنا مؤخرًا في تمكين التخزين المؤقت لـ Hibernate الثاني (للكيانات والمجموعات الشعبية) لتخفيف بعض مشاكل الأداء.

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

يبدو أن الكائنات notfoundexceptions تحدث لأن قاعدة البيانات تحذف صفوف الجدول تحته بيات شتوى. على سبيل المثال ، عندما نحذف أ Parent مع السبات ، سوف مخطط قاعدة البيانات ON DELETE CASCADE لأي Child جهات. من الواضح أن هذا يحدث دون الإسبات المعرفة ، لذلك لا يحصل على فرصة لتحديث ذاكرة التخزين المؤقت من المستوى الثاني (وإزالة أي حذف Child جهات).

نعتقد أن الحل لهذه المشكلة هو الإزالة ON DELETE CASCADE من مخطط قاعدة البيانات لدينا (ولكن حافظ على FOREIGN KEYس). بدلاً من ذلك ، نحتاج إلى تكوين السبات للحذف Child التبعيات مع الحذف العادي SQL والتي ستجعل أيضا تحديث السبات من ذاكرة التخزين المؤقت من المستوى الثاني. أظهرت بعض الاختبارات المحدودة أن هذا النهج يبدو أنه يعمل.

أردت الحصول على بعض ردود الفعل المجتمعية على هذا. هل هناك حلول بديلة (أفضل؟) لمشكلتنا؟ كيف يتعامل الآخرون مع هذا الموقف؟ بشكل عام ، ما هي المقايضات التي يجب مراعاتها عند استخدامها ON DELETE CASCADE في مخطط قاعدة البيانات مع السبات؟

شكرًا.

Answer 1

إذا كنت ستحذف دائمًا من خلال برنامجك ، فأنت تريد إزالة القيد من قاعدة البيانات وتخبر كائن السبات على حذف Cascade لرعاية اللاعبين ذوي الصلة.

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

Answer 2

إذا كنت تستخدم ON DELETE CASCADE في قاعدة البيانات الخاصة بك ، تحتاج إلى إخبار السبات ، مثل هذا:

@OnDelete(action = OnDeleteAction.CASCADE)

هذا يختلف عن

@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)

هذا الأخير يخبر Hibenrate بشيء عن العلاقة بين الذاكرة. أول واحد يحسن حذف عبارات SQL على مستوى قاعدة البيانات. يحتاج السبات إلى معرفة أن DB يعتني بحذف الأطفال.

ألقِ نظرة على هذا الموقع للحصول على شرح جيد لهذه الآلية:

http://eddii.wordpress.com/2006/11/16/hibernate-on-deletecascade-performance/

والتعليق من مطور هذه الميزة:

http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/msg03801.html