متفائل مقابلتأمين متشائمة

Question

لقد فهم الاختلافات بين التفاؤل والتشاؤم تأمين.الآن يمكن للشخص أن يفسر لي عندما كنت استخدم واحدة في العام ؟

ولا الإجابة على هذا السؤال التغيير اعتمادا على ما إذا كان أو لا أنا باستخدام الإجراء المخزن لتنفيذ الاستعلام?

ولكن فقط للتأكد, متفائل يعني "لا قفل الطاولة أثناء القراءة" و متشائم يعني "قفل الطاولة أثناء القراءة."

Answer 1

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

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

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

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

في هذه الحالة يمكنك فتح الصفقة مع TxID ثم إعادة الاتصال باستخدام هذا الرقم.DBMS يحافظ على أقفال يسمح لك لاختيار الدورة من خلال TxID.هذا هو كيف المعاملات الموزعة باستخدام مرحلتين ارتكاب البروتوكولات (مثل XA أو COM+ المعاملات) العمل.

Answer 2

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

تأمين متشائمة يستخدم عند الاصطدام المتوقع.المعاملات التي من شأنها أن تنتهك تزامن هي ببساطة المحظورة.

لتحديد السليم آلية قفل لديك لتقدير كمية من يقرأ ويكتب والتخطيط وفقا لذلك.

Answer 3

متفائل يفترض أن لا شيء سيتغير بينما أنت تقرأ هذا.

متشائم يفترض أن شيئا ما سوف يقفل عليه.

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

معظم تطبيقات الويب على ما يرام مع القذرة يقرأ - في مناسبة نادرة البيانات بالضبط لا رصيده تحديث القادم لا.

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

أوه, و Microsoft SQL server الافتراضي صفحة تأمين - في الأساس صف كنت تقرأ وعدد قليل من جانبي.الصف تأمين أكثر دقة ولكن بوتيرة أبطأ بكثير.فإنه غالبا ما يكون من المفيد وضع المعاملات الخاصة بك إلى قراءة-تلتزم أو لا-قفل لتجنب المآزق أثناء القراءة.

Answer 4

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

يدفع المال الخاص بك ، الخ

Answer 5

أعتقد أكثر واحد القضية عندما متشائم قفل سيكون خيارا أفضل.

التفاؤل تأمين كل مشارك في تعديل البيانات يجب أن نتفق في استخدام هذا النوع من التأمين.ولكن إذا كان شخص ما بتعديل البيانات دون أن تأخذ الرعاية حول إصدار عمود هذا سوف يفسد كل فكرة التفاؤل تأمين.

Answer 6

هناك أساسا اثنين من الأكثر شعبية إجابات.على أول واحد يقول أساسا

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

جواب آخر هو

متفائل (الإصدار) هو أسرع بسبب عدم تأمين ولكن (التشاؤم) تأمين أداء أفضل عند الخلاف مرتفع فمن الأفضل لمنع العمل بدلا من تجاهل ذلك و البدء من جديد.

أو

متفائل قفل يعمل بشكل أفضل عندما يكون لديك نادرة التصادم

كما يتم وضع في هذه الصفحة.

أنا خلقت جوابي لشرح كيفية "الحفاظ على اتصال" ذات صلة "منخفضة التصادم".

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

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

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

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

أنا بعيد عن فهم كيفية تنفيذ MVCC يدويا ولكن أعتقد أن تشغيل المعاملات مع خيار إعادة تشغيل هو المفتاح لفهم هذا الموضوع.تصحيح لي إذا كنت مخطئا في أي مكان.جوابي كان بدافع هذا اليكس Kuznecov الفصل.

Answer 7

في معظم الحالات, متفائل تأمين أكثر كفاءة و يقدم أداء أعلى.عند اختيار بين متشائم ومتفائل تأمين مراعاة ما يلي:

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

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

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

Answer 8

استخدام واحد حالة التفاؤل قفل هو أن يكون التطبيق الخاص بك استخدام قاعدة البيانات للسماح واحد من المواضيع الخاصة بك / يستضيف أن تكون مهمة.هذا هو أسلوب التي قد تأتي في متناول اليدين بالنسبة لي على أساس منتظم.

أفضل مثال يمكن أن يخطر على انتظار مهمة تنفيذها باستخدام قاعدة بيانات مع مواضيع متعددة مدعيا المهام في وقت واحد.إذا كانت مهمة قد وضع 'المتاحة', 'ادعى', "الانتهاء", db الاستعلام يمكن أن تقول شيئا مثل "مجموعة status='ادعى' حيث وضع= "متاحة".إذا كانت المواضيع متعددة في محاولة لتغيير الوضع القائم في هذا الطريق ، ولكن كل أول موضوع سوف تفشل بسبب البيانات القذرة.

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