بديل عن السبات أو الارتباط الأعلى؟ [مغلق

Question

هل هناك بديل قابل للتطبيق عن السبات؟ ويفضل أن يكون شيء لا يبني نفسه على JPA.

مشكلتنا هي أننا نبني نظامًا معقدًا (كما هو الحال في العديد من الكائنات إلى بعضها البعض). يبدو أن السبات مصمم لاستخدامه بشكل أساسي في التطبيقات لمرة واحدة - JSF وما شابه.

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

تفسيراتي السيئة جانبا ، خلاصة القول هي أن السبات لا نحب. يبدو أن Toplink ليس أفضل ، كما أنه يتم كتابته فوق EJB.

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

أي أفكار ، أو هل أطلب شيئًا غير موجود؟

يحرر: أنا آسف لمصطلحات الغموض الخاصة بي ، وأشكركم جميعًا على تصحيحاتك وإجاباتك الثاقبة. أولئك الذين قاموا بتصحيحني ، أنتم جميعًا على صواب ، قصدت JPA ، وليس EJB.

Answer 1

كما ذكرنا ، JPA <> EJB ، فهي ليست مرتبطة. يحدث EJB 3 للاستفادة من JPA ، ولكن هذا كل شيء. لدينا مجموعة من الأشياء التي تستخدم JPA التي لا تقترب حتى من تشغيل EJB.

مشكلتك ليست التكنولوجيا ، إنها تصميمك.

أو ، يجب أن أقول ، إن تصميمك ليس مناسبًا لأي إطار حديث إلى حد كبير.

على وجه التحديد ، أنت تحاول الحفاظ على المعاملات على قيد الحياة على العديد من طلبات HTTP.

وبطبيعة الحال ، فإن معظم المصطلح الشائع هو أن كل طلب في حد ذاته واحد أو أكثر معاملة ، بدلاً من أن يكون كل طلب جزءًا من معاملة أكبر.

هناك أيضًا تشويش واضح عند استخدام مصطلح "عديمة الجنسية" و "معاملة" في نفس المناقشة ، حيث أن المعاملات هي بطبيعتها.

مشكلتك الكبيرة هي ببساطة إدارة معاملاتك يدويًا.

إذا حدثت معاملة على العديد من طلبات HTTP ، وتصادف طلبات HTTP أن تعمل "سريعة جدًا" ، وبعد بعضها البعض ، يجب ألا تواجه أي مشكلة حقيقية حقًا ، باستثناء أنك ستضطر إلى التأكد من أن HTTP الخاص بك تستخدم الطلبات نفس اتصال DB من أجل الاستفادة من مرفق معاملات قواعد البيانات.

هذا هو ، بعبارات بسيطة ، تحصل على اتصال مع ديسيبل ، وازيفه في الجلسة ، وتأكد من أنه طوال مدة المعاملة ، جميع طلبات HTTP الخاصة بك لا تمر ليس فقط تلك الجلسة نفسها ، ولكن بهذه الطريقة أن الاتصال الفعلي لا يزال صالحا. على وجه التحديد ، لا أعتقد أن هناك اتصال JDBC على الرف الذي سيبقى بالفعل على قيد الحياة فاشل أو موازنة التحميل من جهاز إلى آخر.

لذلك ، ببساطة ، إذا كنت ترغب في استخدام معاملات DB ، فأنت بحاجة إلى التأكد من استخدام نفس اتصال DB.

الآن ، إذا كانت المعاملة الطويلة على المدىة "تفاعلات المستخدم" داخلها ، أي تبدأ معاملة DB وانتظر المستخدم "للقيام بشيء" ، ثم ، بكل بساطة ، هذا التصميم خاطئ. أنت لا تريد أن تفعل ذلك ، لأن المعاملات التي عاشت منذ فترة طويلة ، وخاصة في البيئات التفاعلية ، هي ببساطة سيئة. مثل "عبور الجداول" سيئة. لا تفعل ذلك. معاملات الدُفعات مختلفة ، لكن المعاملات التفاعلية الطويلة الحية سيئة.

تريد الحفاظ على معاملاتك التفاعلية على أنها عملية قصيرة.

الآن ، إذا لم تتمكن من التأكد من أنك ستتمكن من استخدام اتصال DB نفسه لمعاملتك ، فعندئذ ، يمكنك تنفيذ المعاملات الخاصة بك. هذا يعني أنك تحصل على تصميم نظامك وتدفقات البيانات كما لو لم يكن لديك قدرة معاملات في النهاية الخلفية.

هذا يعني في الأساس أنك ستحتاج إلى التوصل إلى آليتك الخاصة "لارتكاب" بياناتك.

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

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

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

ضع في اعتبارك ، في كل هذا ، أن تقنية الثبات لا علاقة لها بها. المشكلة هي كيفية استخدام المعاملات الخاصة بك ، بدلاً من التقنية كثيرًا.

Answer 2

إذا كنت بعد مزود JPA آخر (السبات هو واحد من هذه) ثم ألق نظرة على Eclipselink. إنه أكثر ملاءمة بشكل كامل من التنفيذ المرجعي JPA 1.0 لـ TopLink Essentials. في الواقع ، سيكون Eclipselink هو التنفيذ المرجعي JPA 2.0 الذي يتم شحنه باستخدام Glassfish V3 النهائي.

JPA جيد لأنه يمكنك استخدامه داخل وخارج حاوية. لقد كتبت عملاء الأرجوحة الذين يستخدمون JPA لتأثير جيد. لا يحتوي على نفس وصمة العار وأمتعة XML التي جاء بها EJB 2.0/2.1.

إذا كنت بعد حل الوزن أخف وزنا ، فلا تنظر إلى أبعد من ibatis, ، والتي أعتبرها تقنية الثبات المفضلة لدي لمنصة Java. إنه خفيف الوزن ، ويعتمد على SQL (من المدهش مقدار الوقت الذي يقضيه مستخدمو ORM في محاولة لجعل ORM ينتجون SQL جيدًا) ويقومون بنسبة 90-95 ٪ مما يفعله JPA (بما في ذلك التحميل البطيء للكيانات ذات الصلة إذا كنت تريد).

فقط لتصحيح بضع نقاط:

• JPA هي طبقة التورط من EJB ، غير مبنية على EJB ؛
• أي مزود JPA لائق لديه مجموعة كبيرة من التخزين المؤقت ، ويمكن أن يكون من الصعب تحديد كل شيء (سيكون هذا مثالًا جيدًا على "لماذا البساطة معقدة للغاية؟"). ما لم تقم بشيء لم تقم بتوجيهه ، فلا ينبغي أن تكون الاستثناءات مشكلة لكائناتك المدارة. استثناءات وقت التشغيل عادةً معاملات التراجع (إذا كنت تستخدم إدارة معاملات الربيع ومن لا يفعل ذلك؟). سيحافظ المزود على نسخ مخبأة من الأشياء المحملة أو المستمرة. قد يكون هذا مشكلة إذا كنت ترغب في التحديث خارج مدير الكيان (تتطلب تدفق ذاكرة التخزين المؤقت الصريحة أو استخدامها EntityManager.refresh()).

Answer 3

أعتقد أنه يجب أن تنظر إلى أباتشي كايين وهو بديل جيد جدًا للأطر "الكبيرة". مع مصممها اللائق ، يتم تقصير منحنى التعلم بواسطة وثائق جيدة.

Answer 4

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

Answer 5

eBean orm (http://www.avaje.org)

إنه ORM أكثر بساطة للاستخدام.

• يستخدم التعليقات التوضيحية JPA للتخطيط (entity ، onetomany etc)
• API بدون جلسة - لا توجد جلسة السبات أو مدير كيان JPA
• التحميل كسول يعمل فقط
• دعم الكائن الجزئي لمزيد من الأداء
• ضبط الاستعلام التلقائي عبر "AutoFetch"
• تكامل الربيع
• دعم استعلام كبير
• دعم كبير لمعالجة الدُفعات
• خلفية جلب
• جيل DDL
• يمكنك استخدام RAW SQL إذا كنت ترغب في ذلك (جيد مثل Ibatis)

• ترخيص LGPL

• روب.

Answer 6

Bea Kodo (Solarmetric Kodo السابق) هو بديل آخر. وهو يدعم JPA و JDO و EJ3. إنه قابل للتكوين بشكل كبير ويمكن أن يدعم الإحضار المسبق للعدوى ، وفصل/إرفاق الكائنات ، إلخ.

رغم ذلك ، مما وصفته ، يجب أن يكون Toplink قادرًا على التعامل مع مشاكلك. في الغالب ، يبدو أنك بحاجة إلى أن تكون قادرًا على إرفاق/فصل الكائنات من طبقة الثبات مع بدء الطلبات والنهاية.

Answer 7

فقط للرجوع إليه ، لماذا يمثل تصميم OP أكبر مشكلته: تمتد المعاملات عبر طلبات مستخدم متعددة يعني أنه يمكنك الحصول على أكبر عدد من المعاملات المفتوحة في وقت معين كما يوجد مستخدمون متصلون بتطبيقك - تحتفظ المعاملة بالاتصال حتى يتم الالتزام بها /تراجع. مع ألف من المستخدمين المتصلين في وقت واحد ، يمكن أن يعني هذا الآلاف من الاتصالات. معظم قواعد البيانات لا تدعم هذا.

Answer 8

لا يعتمد Hibernate ولا Toplink (Eclipselink) على EJB ، وهما كلاهما من أطراف Pojo (ORM).

وأنا أتفق مع الإجابة السابقة: Ibatis هو بديل جيد لأطر ORM: التحكم الكامل على SQL ، مع آلية التخزين المؤقت الجيدة.

Answer 9

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

عزم الدوران

Answer 10

عندما كنت نفسي أبحث عن بديل لإسبات ، تعثرت عليه منصة الوصول إلى Datanucleus, ، وهو ORM المرخص Apache2. إنه ليس مجرد orm لأنه يوفر ثباتًا واسترجاعًا للبيانات أيضًا في بيانات البيانات الأخرى من RDBMS ، مثل LDAP و DB4O و XML. ليس لدي أي تجربة استخدام ، لكنها تبدو مثيرة للاهتمام.

Answer 11

فكر في كسر نموذجك تمامًا بشيء مثل توكس. إذا كنت بحاجة إلى فصول Java ، فيمكنك تحميل نتيجة XML إلى جدوم.