سؤال

أحاول تحقيق نوع من سلوك المعاملات المتداخلة باستخدام خيارات التحكم في معاملات Nhibernate وخيارات FlushMode ، لكن الأمور أصبحت مربكة بعض الشيء بعد القراءة الكبيرة ، لذا فإن أي تأكيد حول الحقائق التي سردها أدناه ستكون مفيدة للغاية.

ما أريده هو فتح معاملة كبيرة واحدة تنقسم في المعاملات الصغيرة. تخيل السيناريو التالي:

  • يفتح TX1 TX ويدرج سجل الشخص ؛
  • يفتح TX2 TX ويقوم بتحديث اسم هذا الشخص إلى P2 ؛
  • TX2 يرتكب.
  • يفتح TX3 TX ويقوم بتحديث اسم هذا الشخص إلى P3 ؛
  • تراجع TX3.
  • TX1 يرتكب.

أود أن أرى NH يرسل إدراجًا وتحديث TX2 إلى قاعدة البيانات ، فقط تجاهل TX3 ، حيث تم ترحيله.

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

لقد حاولت أيضًا استخدام FlushMode = ارتكاب وفتح المعاملات المتداخلة ، لكنني اكتشفت ذلك ، لأن ADO.NET ، المعاملات المتداخلة هي ، في الواقع ، نفس المعاملة دائمًا.

لاحظ أنني لا أحاول تحقيق سلوك "الكل أو لا شيء". أنا أبحث أكثر إلى طريقة SavePoint في العمل. هل هناك طريقة للقيام بذلك (نقاط توفير) مع NH؟

شكرا لكم مقدما.

فيليب

هل كانت مفيدة؟

المحلول

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

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

  • تابع على الخطأ: إذا أردنا أنه حتى لو كان ذلك في خطأ في المعاملة ، فإن الحاوية الأخرى تلتزم ، فإن حاوية UOW تستخدم جلسات مختلفة لكل "معاملة" وتطرد كل تكساس في نهاية عملها ؛
  • التراجع عن الخطأ: إذا كنا نريد ذلك في تراجع الجلسة (بسبب خطأ أو تراجع عن العمل) يتم ترحيل كل معاملة أخرى ، فإن حاوية UOW تستخدم نفس الجلسة لجميع المعاملات المتداخلة وتدحرج الجميع في النهاية.

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

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

يعتبر،

فيليب

نصائح أخرى

Nhibernate لا يدعم المعاملات المتداخلة. يمكن أن يكون لكل ISENESS معاملة نشطة واحدة على الأكثر. لست متأكدًا مما تحاول إنجازه لأن سيناريو مثالك لا معنى لي. ارتكاب المعاملة 1 بعد الإدراج سيكون له نفس التأثير.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top