System.Treatactions Infrastructure في العالم .NET

هل شاهدت بنية مثل using (var scope = new TransactionScope(TransactionScopeOption.Required)) في C #؟ هذا يعني أن الكود الذي يتم تشغيله في كتلة الاستخدام في المعاملة وبعد الخروج من هذا الحظر ، سيتم الالتزام بالتغييرات أو التراجع عنها. يبدو مفهوما حتى تبدأ الحفر أعمق. وكلما حفر أعمق ، يصبح "أغرب وأغرب". على أي حال ، عندما أصبحت أكثر دراية بفئة TransactionScope ، وبصفة عامة ، مع معاملات .NET ، نشأت مجموعة كاملة من الأسئلة.

ما هي فئة TransactionScope ؟ بمجرد استخدام بنية using (var scope = new TransactionScope()) ، هل يصبح كل شيء في برنامجنا معاملات على الفور؟ ما هي "إدارة الموارد" و "مدير المعاملات"؟ هل يمكنني كتابة مدير الموارد الخاص بي وكيف "يتصل" بمثيل TransactionScope تم إنشاؤه؟ ما هي المعاملة الموزعة وهل صحيح أن المعاملة الموزعة في SQL Server أو Oracle Database هي نفس معاملة .NET الموزعة؟

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

مقدمة

ما هي المعاملات وما هي المشاكل التي يحلونها؟

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


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

من الناحية الرياضية ، يمكننا أن نقول أنه فيما يتعلق بالنظام ، هناك متغير نود الحفاظ عليه. على سبيل المثال ، المبلغ في كلا الحسابين: من الضروري أن يظل المبلغ كما هو قبل العملية بعد التحويل (تحويل الأموال). بالمناسبة ، في المثال الكلاسيكي لتحويل الأموال ، تظهر المحاسبة أيضًا - وهي مجال موضوع نشأ فيه مفهوم المعاملة بشكل طبيعي.

نوضح مثال تحويل الأموال بين حسابين. الصورة الأولى توضح الموقف عندما تم نقل 50 روبل من الحساب رقم 1 إلى الحساب رقم 2 بنجاح. يشير اللون الأخضر إلى أن النظام في حالة مقبولة (البيانات كاملة).


الآن تخيل أن التحويل يتم خارج المعاملة وبعد سحب الأموال من الحساب رقم 1 ، حدث فشل ، بسبب عدم إيداع الأموال المسحوبة في الحساب رقم 2. سيكون النظام في حالة غير مقبولة (اللون الأحمر).


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


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

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

ما المعاملات تعتبر هنا

الفوائد التي تقدمها المعاملات معروفة. لذلك ، للحفاظ على سلامة البيانات ، هل نحن بحاجة إلى قاعدة بيانات علائقية ، لأن هذا هو المكان الذي تتم فيه المعاملات؟ ليس حقا لقد قيل أعلاه أن مفهوم المعاملة يعتمد على السياق ، والآن سننظر بإيجاز في المعاملات التي يمكن أن نتحدث عنها عند مناقشة أنظمة المعلومات.

بادئ ذي بدء ، نفصل بين مفاهيم معاملات المجال الموضوع (المعاملات التجارية) ومعاملات النظام. يمكن تنفيذ الثاني في أماكن مختلفة وبطرق مختلفة.

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

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

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

هناك خيارات أكثر إثارة للاهتمام. تقدم لغات البرمجة الصناعية الحديثة (C # و Java في المقام الأول) أدوات مصممة خصيصًا لتنظيم المعاملات التي تنطوي على أنظمة فرعية مختلفة تمامًا ، وليس فقط DBMS. في هذا المنشور ، سوف نسمي برمجيات المعاملات. في حالة C # ، هذه معاملات من مساحة اسم System.Transactions (المثال الثاني) ، ويتم وصفها أدناه.

قبل الانتقال إلى معاملات System.Transactions ، لا يمكن للمرء أن يفشل في ذكر ظاهرة أكثر إثارة للاهتمام. أدوات System.Transactions تسمح للمبرمج بتنفيذ ذاكرة المعاملة البرنامجية بشكل مستقل. في هذه الحالة ، يتم تضمين عمليات البرنامج التي تؤثر على حالة النظام (في حالة لغات البرمجة الإلزامية الكلاسيكية هذه هي عملية التعيين) افتراضيًا في المعاملات التي يمكن الالتزام بها واسترجاعها بنفس طريقة معاملات DBMS. مع هذا النهج ، تقل الحاجة إلى استخدام آليات التزامن (في C # - lock ، وفي Java - synchronized ). ومن التطورات الأخرى لهذه الفكرة ، ذاكرة معاملات البرنامج ، المدعومة على مستوى المنصة (المثال الثالث). من المتوقع العثور على هذه المعجزة بلغة تفوق أناقتها قابليتها للتطبيق الصناعي - Clojure. ولغات الفلاحين العاملين ، توجد مكتبات في المكونات توفر وظائف ذاكرة المعاملات البرنامجية.

يمكن أن تشمل معاملات النظام عدة أنظمة معلومات ، وفي هذه الحالة يتم توزيعها. يمكن أن تكون موزعة معاملات DBMS والبرامج ؛ كل هذا يتوقف على وظيفة ما تدعمه أداة معاملة معينة. وتناقش المعاملات الموزعة أكثر تفصيلا في القسم المقابل. سأقدم صورة لتسهيل فهم الموضوعات التي تمت مناقشتها.

TL ؛ قسم DR

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

المعاملات القائمة على نظام. المعاملات

ما هذا

في عالم .NET ، يوجد إطار برنامج مصمم من قبل منشئي نظام أساسي لإدارة المعاملات. من وجهة نظر مبرمج معاملات ، يتكون هذا الإطار من System.Transactions TransactionOptions و TransactionOptions و TransactionOptions و TransactionOptions System.Transactions مساحة اسم System.Transactions . إذا تحدثنا عن .NET Standard ، فسيكون كل هذا متاحًا بدءًا من الإصدار 2.0 .

تستند المعاملات من مساحة الاسم System.Transactions إلى معيار X / Open XA من The Open Group . يقدم هذا المعيار العديد من المصطلحات التي تمت مناقشتها أدناه ، والأهم من ذلك ، وصف المعاملات الموزعة ، والتي يتم تغطيتها أيضًا في هذا المنشور في قسم خاص. يعتمد تنفيذ معاملات البرامج في الأنظمة الأساسية الأخرى ، على سبيل المثال ، Java ، على نفس المعيار.

حالة استخدام المعاملة النموذجية لمبرمج C # كما يلي:

 using (var scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required)) { // -  ,    . scope.Complete(); } 

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

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

مديري الموارد

لشيء ما لدعم المعاملات على أساس System.Transactions ، فمن الضروري أن تمتلك معلومات أن المعاملات جارية حاليا ، وأنه مسجل في بعض سجل المشاركين في الصفقة. يمكنك الحصول على معلومات حول ما إذا كان عمل المعاملات قيد التنفيذ عن طريق التحقق من الخاصية الثابتة Current لفئة System.Transactions.Transaction . يؤدي إدخال كتلة الاستخدام من النوع المشار إليه أعلاه إلى تعيين هذه الخاصية فقط ، إذا لم يتم تعيينها من قبل. وللتسجيل كمشارك في إحدى المعاملات ، يمكنك استخدام أساليب من النوع Transaction.Enlist Smth . بالإضافة إلى ذلك ، تحتاج إلى تنفيذ الواجهة المطلوبة بواسطة هذه الطرق. مدير الموارد - هذا هو مجرد "شيء" يدعم التفاعل مع المعاملات من System.Transactions (يتم تقديم تعريف أكثر تحديدًا أدناه).

ما هي مديري الموارد؟ إذا كنا نعمل من C # مع DBMS ، على سبيل المثال ، SQL Server أو Oracle Database ، فإننا نستخدم عادة برامج التشغيل المناسبة ، وهي موارد الإدارة. في التعليمات البرمجية ، يتم تمثيلهم بواسطة أنواع System.Data.SqlClient.SqlConnection و Oracle.ManagedDataAccess.Client.OracleConnection . يقولون أيضًا أن MSMQ يدعم المعاملات المستندة إلى System.Transactions . تسترشد بالمعرفة والأمثلة المستقاة من الإنترنت ، يمكنك إنشاء مدير الموارد الخاص بك. ويرد أبسط مثال في القسم التالي.

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

بشكل أكثر تحديدًا ، مدير الموارد هو مثيل لفئة تقوم بتنفيذ واجهة System.Transactions.IEnlistmentNotification الخاصة. يتم تسجيل مثيل الفئة ، وفقًا لتوجيهات العميل ، كمشارك في المعاملة باستخدام الخاصية الثابتة System.Transactions.Transaction.Current . بعد ذلك ، يستدعي مدير المعاملات أساليب الواجهة المحددة عند الضرورة.


من الواضح أنه في وقت التشغيل ، قد تتغير مجموعة مديري الموارد المشاركين في المعاملة. على سبيل المثال ، بعد إدخال كتلة الاستخدام ، يمكننا أولاً القيام بشيء ما في SQL Server ، ثم في Oracle Database. بناءً على هذه المجموعة من مديري الموارد ، يتم تحديد مدير المعاملات المستخدم. لكي تكون أكثر دقة ، يتم تحديد بروتوكول المعاملة المستخدم من خلال مجموعة من مديري الموارد ، ويتم تحديد مدير المعاملات الذي يدعمه على أساس البروتوكول. سننظر في بروتوكولات المعاملات في وقت لاحق عندما نتحدث عن المعاملات الموزعة. تسمى آلية اختيار مدير المعاملات المناسب تلقائيًا في وقت التشغيل عند تغيير مديري الموارد المشاركين في المعاملة ترويج المعاملات.

أنواع مديري الموارد

يمكن تقسيم مديري الموارد إلى مجموعتين كبيرتين: دائم ومتغير.

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

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

باستخدام TransactionScope

عند إنشاء كائن من نوع TransactionScope يمكنك تحديد بعض المعلمات.

أولاً ، هناك إعداد يخبر وقت التشغيل بما يحتاج إليه:

1. استخدم معاملة موجودة بالفعل في هذا الوقت ؛
2. تأكد من إنشاء واحدة جديدة.
3. على العكس ، قم بتنفيذ التعليمات البرمجية داخل كتلة using خارج المعاملة.

تعداد System.Transactions.TransactionScopeOption هو المسؤول عن كل هذا.

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

يعد تحديد مستوى عزل المعاملة أثناء الإنشاء TransactionScopeبمثابة نصيحة لمديري الموارد. قد لا تدعم حتى جميع المستويات المذكورة System.Transactions.IsolationLevel. بالإضافة إلى ذلك ، يجب أن يؤخذ في الاعتبار أنه عند استخدام تجمع الاتصال للعمل مع قاعدة البيانات ، فإن الاتصال الذي تم تغيير مستوى عزل المعاملة به سوف يحتفظ بهذا المستوى عند الرجوع إلى التجمع . الآن ، عندما يتلقى المبرمج هذا الاتصال من التجمع ويعتمد على القيم الافتراضية ، سوف يلاحظ سلوكًا غير متوقع.

سيناريوهات العمل النموذجي cTransactionScopeوالمخاطر الكبيرة (وهي المعاملات المتداخلة) مغطاة جيدًا في هذه المقالة عن "Habr" .

تطبيق المعاملات البرمجيات

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

في كل حالة ، سيكون من المفيد بناء التكلفة:

1. دمج العمليات في البنية التحتية للمعاملات البرمجية (تحتاج هذه العمليات إلى أن تكون على دراية TransactionScopeبأشياء أخرى كثيرة) ؛
2. الحفاظ على هذه البنية التحتية (على سبيل المثال ، تكلفة استئجار المعدات مع ويندوز على متن الطائرة) ؛
3. تدريب الموظفين (لأن موضوع معاملات .NET غير شائع).

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

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

مثال على مدير موارد متقلب

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

 internal sealed class Stm<T> : System.Transactions.IEnlistmentNotification { private T _current; private T _original; private bool _enlisted; public T Value { get { return _current; } set { if (!Enlist()) { _original = value; } _current = value; } } public Stm(T value) { _current = value; _original = value; } private bool Enlist() { if (_enlisted) return true; var currentTx = System.Transactions.Transaction.Current; if (currentTx == null) return false; currentTx.EnlistVolatile(this, System.Transactions.EnlistmentOptions.None); _enlisted = true; return true; } #region IEnlistmentNotification public void Commit(System.Transactions.Enlistment enlistment) { _original = _current; _enlisted = false; } public void InDoubt(System.Transactions.Enlistment enlistment) { _enlisted = false; } public void Prepare(System.Transactions.PreparingEnlistment preparingEnlistment) { preparingEnlistment.Prepared(); } public void Rollback(System.Transactions.Enlistment enlistment) { _current = _original; _enlisted = false; } #endregion IEnlistmentNotification } 

يمكن ملاحظة أن الشرط الرسمي الوحيد هو تنفيذ الواجهة System.Transactions.IEnlistmentNotification. من المثير للاهتمام ، والأساليب Enlist(التي ليست جزءا System.Transactions.IEnlistmentNotification) و Prepare. تقوم الطريقة Enlistبالتحقق مما إذا كانت الشفرة المحددة تعمل في إطار المعاملة ، وإذا كان الأمر كذلك ، فإنها تسجل مثيلًا لفئتها كمدير موارد غير ثابت. Prepareيتم استدعاء الطريقة من قبل مدير المعاملات قبل تنفيذ التغييرات. يشير مدير الموارد لدينا إلى استعداده للالتزام من خلال استدعاء الأسلوب System.Transactions.PreparingEnlistment.Prepared.

فيما يلي رمز يعرض مثالًا لاستخدام مدير الموارد لدينا:

 var stm = new Stm<int>(1); using (var scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required)) { stm.Value = 2; scope.Complete(); } 

إذا قمت usingبقراءة العقار مباشرة بعد الخروج من الكتلة stm.Value، فسيتم توقع القيمة المتوقعة هناك 2. إذا مكالمة لإزالة scope.Complete، ثم يتم إرجاع المعاملة بعيدا والخاصية stm.Valueهي قيمة 1معينة قبل بدء العملية.

يتم عرض تسلسل مبسط للمكالمات عند العمل مع المعاملات System.Transactionsفي الرسم البياني أدناه.


يمكن ملاحظة أنه في هذا المثال ، لا يتم النظر في جميع الإمكانيات التي توفرها البنية التحتية System.Transactions. سننظر فيها بشكل كامل بعد التعرف على بروتوكولات المعاملات والمعاملات الموزعة في القسم التالي.

TL ؛ قسم DR

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

مدير الموارد غير المتناسق هو فئة تطبق الواجهة System.Transactions.IEnlistmentNotificationفي الطريقةPrepareتأكيد استعدادها لارتكاب التغييرات أو ، على العكس ، الإشارة إلى تراجع التغييرات. عندما يقوم المتصل بشيء ما مع مدير الموارد ، فإنه يتحقق لمعرفة ما إذا كانت المعاملة مفتوحة الآن ، وإذا كان مفتوحًا ، فسيتم تسجيل الدخول باستخدام هذه الطريقة System.Transactions.Transaction.EnlistVolatile.

المعاملات الموزعة

ما هذا

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

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

بروتوكولات المعاملات

بروتوكول المعاملات هو مجموعة من المبادئ التي تتفاعل من خلالها التطبيقات المتضمنة في المعاملة. في عالم .NET ، يتم العثور على البروتوكولات التالية بشكل شائع.

خفيفة الوزن. لا يتم استخدام أكثر من مدير موارد دائم. تحدث جميع تفاعلات المعاملات داخل نفس مجال التطبيق ، أو يدعم مدير الموارد الترويج والالتزام بمرحلة واحدة (تنفذ IPromotableSinglePhaseNotification).

OleTx. يُسمح بالتشغيل البيني بين مجالات تطبيق متعددة وأجهزة كمبيوتر متعددة. يمكنك استخدام العديد من مديري الموارد دائم. يجب أن تعمل جميع أجهزة الكمبيوتر المشاركة بنظام Windows. استخدم استدعاءات الإجراءات عن بُعد (RPCs).

WS-AT.يُسمح بالتشغيل البيني بين مجالات تطبيق متعددة وأجهزة كمبيوتر متعددة. يمكنك استخدام العديد من مديري الموارد دائم. قد تعمل أجهزة الكمبيوتر المشاركة على أنظمة تشغيل مختلفة ، وليس فقط Windows. يتم استخدام بروتوكول نقل النص التشعبي (HTTP).

وقد لوحظ أعلاه أن بروتوكول المعاملة الحالية يؤثر على اختيار مدير المعاملة ، وأن خصائص موارد الرقابة التي تنطوي عليها المعاملة تؤثر على اختيار البروتوكول. الآن نحن قائمة مديري المعاملات المعروفة.

مدير معاملات خفيفة الوزن (LTM) . المقدمة في .NET Framework 2.0 والإصدارات الأحدث. يدير المعاملات باستخدام بروتوكول Lightweight.

مدير معاملات Kernel (KTM). المقدمة في نظامي التشغيل Windows Vista و Windows Server 2008. تدير المعاملات باستخدام بروتوكول Lightweight. يمكنه استدعاء نظام ملفات معاملات (TxF) وسجل معاملات (TxR) على نظامي التشغيل Windows Vista و Windows 2008.

منسق المعاملات الموزعة (MSDTC) . يدير المعاملات باستخدام بروتوكولي OleTx و WS-AT.

يجب أيضًا مراعاة أن بعض مديري الموارد لا يدعمون جميع البروتوكولات المدرجة. على سبيل المثال ، لا تدعم MSMQ و SQL Server 2000 Lightweight ، لذلك ستتم إدارة المعاملات التي تنطوي على MSMQ أو SQL Server 2000 بواسطة MSDTC ، حتى لو كانا المشتركين الوحيدين. من الناحية الفنية ، ينشأ هذا القيد عن حقيقة أن مديري الموارد المحددين ينفذون ، بالطبع ، الواجهةSystem.Transactions.IEnlistmentNotificationلا تنفذ الواجهة System.Transactions.IPromotableSinglePhaseNotification. يتضمن ، من بين أشياء أخرى ، طريقة Promoteيستدعي وقت التشغيل ، إذا لزم الأمر ، للتبديل إلى مدير معاملات أكثر حدة.

يجب أن يصبح غموض مفهوم المعاملة الموزعة واضحًا الآن. على سبيل المثال ، يمكنك تعريف معاملة موزعة كمعاملة تشارك فيها:

1. اثنين على الأقل من مديري الموارد ؛
2. مديري الموارد المتغيرة بشكل تعسفي واثنين على الأقل من العمر الطويل ؛
3. يوجد اثنان على الأقل من مديري الموارد بالضرورة على أجهزة كمبيوتر مختلفة.

لذلك ، من الأفضل أن توضح دائمًا أي معاملات معينة متورطة.

وفي هذا السياق ، تتم مناقشة MSDTC بشكل أساسي. إنه أحد مكونات برامج Windows التي تدير المعاملات الموزعة. هناك واجهة رسومية لتكوين ومراقبة المعاملات ، والتي يمكن العثور عليها في الأداة المساعدة "خدمات المكونات" ، تتبع المسار "أجهزة الكمبيوتر - جهاز الكمبيوتر - منسق المعاملات الموزعة - DTC المحلي".


للتكوين ، حدد عنصر "خصائص" في قائمة السياق لعقدة "DTC المحلية" ، ولمراقبة المعاملات الموزعة ، حدد عنصر "إحصائيات المعاملات" في اللوحة المركزية.

تثبيت ثنائي الطور

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

بشكل عام ، فإن جوهر هذا البروتوكول هو على النحو التالي. خلال المرحلة الأولىيعد مديرو الموارد المشتركون في المعاملة معلومات كافية للتعافي من الفشل (إذا كان مدير موارد طويل الأجل) ولإنجازه الناجح نتيجة الالتزام. من وجهة نظر تقنية ، يشير مدير الموارد إلى أنه أكمل المرحلة الأولى من خلال استدعاء الطريقة System.Transactions.PreparingEnlistment.Preparedفي الطريقة Prepare. أو يمكن أن يقوم مدير الموارد بإعلامك بأنه قد تم التراجع عن التغييرات عن طريق استدعاء الطريقة ForceRollback.

عندما "صوت" جميع مديري الموارد المشاركين في المعاملة ، أي أنهم أبلغوا مدير المعاملة ما إذا كانوا يريدون الالتزام بالتغييرات أم لا ، فإن المرحلة الثانية تبدأ. في هذا الوقت ، يُطلب من مديري الموارد الالتزام بالتغييرات (إذا صوت جميع المشاركين على الإصلاح) أو رفض التغييرات (إذا صوت مشارك واحد على الأقل للتراجع). من الناحية الفنية، يمكن التعبير عن هذا استدعاءات الأسلوب Commitو Rollbackالتي تنفذ مديري الموارد، والتي تتسبب في أسلوب System.Transactions.Enlistment.Done.

يمكن لمدير الموارد أيضًا استدعاء الأسلوب System.Transactions.Enlistment.Doneخلال المرحلة الأولى. في هذه الحالة ، من المفهوم أنه لن يرتكب أي تغييرات (على سبيل المثال ، يعمل فقط للقراءة) ولن يشارك في المرحلة الثانية. اقرأ المزيد حول الالتزام ثنائي الطور في Microsoft .

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

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

الغش ورقة على واجهات System.Tactactions

شيء صعب. لفرز الأشياء قليلاً ، سأصف باختصار واجهات مساحة الاسم الرئيسية System.Transactionsاللازمة لإنشاء مدير موارد. هنا هو مخطط الفصل.



IEnlistmentNotification. مدير الموارد بتنفيذ هذه الواجهة. يستدعي مدير المعاملات الأساليب المطبقة بالترتيب التالي. خلال المرحلة الأولى ، يطلق على الطريقة Prepare(ما لم تجتمع النجوم لاستدعاء الطريقة ISinglePhaseNotification.SinglePhaseCommit، كما هو موضح في الفقرة التالية). بموجب هذه الطريقة ، يحفظ مدير الموارد المعلومات اللازمة للتعافي من الفشل ، ويستعد للالتزام النهائي بالتغييرات من جانبه ، ويصوت لارتكاب التغييرات أو التراجع عنها. إذا كان هناك يأتي في المرحلة الثانية، وهذا يتوقف على مدى توافر الموارد والسيطرة على نتائج التصويت للمعاملة السيطرة هي واحدة من ثلاث طرق: Commit، InDoubt، Rollback.

ISinglePhaseNotification.يقوم مدير الموارد بتنفيذ هذه الواجهة إذا أراد تزويد مدير المعاملات بفرصة تحسين التنفيذ عن طريق تقليل مرحلة الالتزام الثانية. إذا رأى مدير المعاملة مدير موارد واحدًا فقط ، فسيحاول في مرحلة الالتزام الأولى طريقة مدير الموارد SinglePhaseCommit(بدلاً من ذلك IEnlistmentNotification.Prepare) وبالتالي يستبعد التصويت والانتقال إلى المرحلة الثانية. هذا النهج له مزايا وعيوب ، والتي كتبها مايكروسوفت بوضوح أكثر عن هنا .

ITransactionPromoter. يقوم مدير الموارد بتنفيذ هذه الواجهة (ليس فقط مباشرة ، ولكن من خلال الواجهةIPromotableSinglePhaseNotification) ، إذا كان يريد تزويد مدير المعاملات بالقدرة على الالتزام ببروتوكول Lightweight حتى عند الاتصال عن بُعد ، حتى تنشأ شروط أخرى تتطلب تعقيد البروتوكول. عندما تحتاج إلى تعقيد البروتوكول ، سيتم استدعاء الطريقة Promote.

IPromotableSinglePhaseNotification. يقوم مدير الموارد بتنفيذ هذه الواجهة من أجل ، أولاً ، تنفيذ الواجهة ITransactionPromoter، وثانياً ، بحيث يمكن لمدير المعاملة استخدام الالتزام أحادي الطور وطرق الاتصال IPromotableSinglePhaseNotification.SinglePhaseCommitو IPromotableSinglePhaseNotification.Rollback. يستدعي مدير المعاملة طريقة IPromotableSinglePhaseNotification.Initializeلتمييز التسجيل الناجح لمدير الموارد بطريقة مبسطة. أكثر أو أقل ، يمكن فهم ذلك من مستند Microsoft .

دعونا ننظر إلى أكثر من ذلك بقليلSystem.Transactions.Enlistmentوورثته. يتم توفير هذا النوع من المثال بواسطة مدير المعاملات عندما يستدعي أساليب الواجهة التي يطبقها مدير الموارد.



تجنيد. يمكن لمدير الموارد استدعاء طريقة واحدة من هذا النوع - Done، - للإشارة إلى الإكمال الناجح لجزءه من العمل.

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

SinglePhaseEnlistment. باستخدام مثيل من هذا النوع ، يمكن لمدير الموارد إرسال المعلومات إلى مدير المعاملات حول نتائج عمله باستخدام نظام مبسط (التزام أحادي المرحلة).

البرمجيات الموزعة قيود المعاملات والبدائل

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

إذا كان منشئ النظام يفضل إعادة الإجابة إلى المستخدم في أقرب وقت ممكن ، مع تأجيل تنسيق البيانات في وقت لاحق ، فسيكون حل آخر أكثر ملاءمة له. في سياق نظرية Brewer's ( CAP theorem ) ، يمكننا القول أن المعاملات الموزعة مناسبة للحالات التي يكون فيها تناسق البيانات أكثر أهمية من التوفر.

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

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

بالانتقال إلى بدائل المعاملات الموزعة ، يمكننا أن نلاحظ الحلول القائمة على خدمات الرسائل ، مثل RabbitMQ و Apache Kafka. في هذا المنشور على "Habré" أربعة حلول مثل:

1. , , ;
2. , (Transaction Log Tailing);
3. , ;
4. (Event Sourcing).

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

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

هل هو كذلك في .NET Core؟

في .NET Core (وحتى في .NET Standard) ، توجد جميع الأنواع اللازمة لتنظيم المعاملات وإنشاء مدير الموارد الخاص بك. لسوء الحظ ، في .NET Core ، المعاملات القائمة System.Transactionsلها قيود خطيرة: إنها تعمل فقط مع بروتوكول Lightweight. على سبيل المثال ، إذا تم استخدام مديري موارد متينين في التعليمات البرمجية ، ثم في وقت التشغيل ، ستخلق البيئة استثناء بمجرد استدعاء المدير الثاني.

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

من التجربة ، يمكنك التحقق من الاختلافات في المعاملات الموزعة في .NET Framework وفي .NET Core عن طريق كتابة نفس الرمز وتجميعه وتشغيله على منصات مختلفة.


مشاريع جاهزة للبناء على جيثب .

تشغيل المثال ل. NET الأساسية فشل. يعتمد مكان ونوع الاستثناء الذي تم طرحه على ترتيب استدعاء DBMS ، ولكن على أي حال ، يشير هذا الاستثناء إلى عملية معاملة غير صالحة. ينجح تشغيل مثال .NET Framework إذا كان MSDTC يعمل في هذا الوقت ؛ ومع ذلك ، في الواجهة الرسومية لـ MSDTC ، يمكنك مراقبة تسجيل معاملة موزعة.

المعاملات الموزعة و WCF

Windows Communication Foundation (WCF) هو إطار عمل .NET لتنظيم واستدعاء خدمات الشبكة. بالمقارنة مع أساليب REST و ASP.NET Web API الأكثر عصرية ، فإن له مزايا وعيوب خاصة به. يعتبر WCF صديقًا جيدًا مع معاملات .NET ، وفي عالم .NET Framework ، من الملائم استخدامه لتنظيم المعاملات الموزعة بين العميل والخدمة.

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

كيف يعمل WCF

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

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

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

يدعم WCF أنواعًا مختلفة من النقل والتشفير وغيرها من المعلمات التقنية الدقيقة. معظمهم متحدون بمفهوم "الربط" (Binding). هناك ثلاث معلمات مهمة لخدمة WCF:

1. العنوان الذي يتوفر فيه
2. ملزم
3. العقد (واجهات).

يتم تعيين كل هذه المعلمات في ملفات تكوين الخدمة والعميل.

في شركتنا ، يستخدم WCF (مع وبدون معاملات موزعة) على نطاق واسع في المنتجات المنفذة ، ومع ذلك ، بالنظر إلى اتجاهات الموضة ، لا يزال استخدامه في منتجات جديدة قيد البحث.

كيفية بدء المعاملات الموزعة في WCF

لبدء المعاملات القائمة في WCF System.Transactions، يحتاج المبرمج إلى تعيين العديد من السمات في الكود ، وتأكد من أن الارتباطات المستخدمة تدعم المعاملات الموزعة ، وأنه مكتوب على العميل وفي الخدمة ، transactionFlow="true"وأن مدير معاملة مناسب يعمل على جميع أجهزة الكمبيوتر المعنية (على الأرجح ، سيكون MSDTC).

روابط المعاملات الموزعة: NetTcpBinding و NetNamedPipeBinding و WSHttpBinding و WSDualHttpBinding و WSFederationHttpBinding.

يجب تمييز طريقة (تشغيل) واجهة الخدمة بسمة System.ServiceModel.TransactionFlowAttribute. بعد ذلك ، مع بعض معلمات السمات وعند تعيين معلمة TransactionScopeRequiredالسمة ، System.ServiceModel.OperationBehaviorAttributeسيتم توزيع المعاملة بين العميل والخدمة. بالإضافة إلى ذلك ، بشكل افتراضي ، تعتبر الخدمة للتصويت على الالتزام بالمعاملة ، ما لم يتم طرح استثناء في وقت التشغيل. لتغيير هذا السلوك ، يجب عليك تعيين قيمة معلمة TransactionAutoCompleteالسمة المقابلة System.ServiceModel.OperationBehaviorAttribute.

TL ؛ قسم DR

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

WCF هي إحدى الأدوات القياسية والمثبتة لإنشاء الخدمات والوصول إليها في عالم .NET ، حيث تدعم عدة أنواع من النقل والتشفير. WCF صديقان حميمان للغاية مع المعاملات الموزعة على أساس System.Transactions. يتمثل إعداد المعاملات الموزعة لـ WCF في ترميز الرمز بعدة سمات وإضافة كلمتين في ملفات تكوين الخدمة والعميل. ليست كل روابط WCF تدعم المعاملات الموزعة. بالإضافة إلى ذلك ، من الواضح أن المعاملات في WCF لها نفس القيود دون استخدام WCF. يتيح لك .NET Framework الأساسي حتى الآن الوصول إلى الخدمات على WCF فقط ، بدلاً من إنشائها.

خاتمة سرير

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

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

مديري الموارد دائمة ومتقطعة. يدعم مديرو الموارد طويلة الأجل استعادة البيانات بعد فشل النظام. عادة ما تقدم برامج تشغيل DBMS لـ .NET هذه الوظائف. لا تدعم مديري الموارد المتقطعة الاسترداد بعد عطل فادح. يمكن اعتبار ذاكرة المعاملات البرنامجية - طريقة لإدارة الكائنات في RAM - كمثال لمدير الموارد المتقلب.

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

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

المعاملات الموزعة من خلال WCF. WCF هو أحد أدوات .NET القياسية لإنشاء خدمات استدعاء ، والتي تدعم أيضًا البروتوكولات الموحدة. بمعنى آخر ، يمكن الوصول إلى خدمات WCF التي تم تكوينها بطريقة محددة من أي تطبيق ، وليس فقط .NET أو Windows. لإنشاء معاملة موزعة على رأس WCF ، تحتاج إلى ترميز الأنواع التي تشكل الخدمة بسمات إضافية وإجراء تغييرات طفيفة على ملفات تكوين الخدمة والعميل. لا يمكنك إنشاء خدمات WCF في .NET Core و .NET Standard ، ولكن يمكنك إنشاء عملاء WCF.

مثال لفحص System.Tactactions على جيثب