ایجاد شده توسط Paul. Robinson در 19 آوریل 2013 6:32 صبح. آخرین اصلاح شده توسط Paul. Robinson در تاریخ 13 مارس 2015 12:15 بعد از ظهر.

من از این مقاله به عنوان مکانی برای جامعه استفاده می کنم تا مجموعه ای از پست های وبلاگ را که آماده می کنم مرور کند.

برنامه این است که Judcon My را پایه گذاری کنید: بوستون تقریباً در مورد این سری از پست های وبلاگ صحبت کنید. مثالهای کد طراحی فعلی API جبران خسارت را نشان می دهد. من همچنین در انتهای صحبت ، بخش هایی را اضافه می کنم تا آنچه را که تاکنون اجرا کرده ایم و نقشه راه آینده خود را توضیح دهید. من مطمئن نیستم که چه مقدار از این موارد را در پست های وبلاگ پوشش خواهم داد. شاید من یک قسمت 5 داشته باشم ، که این را پوشش می دهد.

جبران معاملات: وقتی اسید خیلی زیاد است.

قسمت 1: مقدمه

معاملات اسیدی ابزاری مفید برای توسعه دهندگان برنامه است و حتی در صورت عدم وجود خرابی می تواند ضمانت های بسیار قوی را ارائه دهد. با این حال ، معاملات اسید همیشه برای هر موقعیتی مناسب نیست. در این سری از پست های وبلاگ. من چندین سناریو از این دست را ارائه می دهم و نشان می دهم که چگونه می توان از یک مدل معامله غیر اسید جایگزین استفاده کرد.

خاصیت جداسازی یک معامله اسیدی به طور معمول از طریق کنترل همزمانی خوش بینانه [Ref] یا بدبین [Ref] حاصل می شود. اگر مدت زمان معامله بیش از چند ثانیه باشد ، هر دو رویکرد می توانند تأثیرات منفی بر کلاسهای خاصی از برنامه ها ایجاد کنند. این اغلب می تواند در مورد معاملات مربوط به شرکت کنندگان کند (به عنوان مثال انسان) یا کسانی که از طریق شبکه های تأخیر بالا توزیع می شوند (مانند اینترنت) توزیع شود. همچنین ، برخی از اقدامات به سادگی قابل برگشت نیستند. مانند ارسال ایمیل یا دعوت برخی از خدمات شخص ثالث.

یک استراتژی رایج برای برنامه هایی که نمی توانند از اسید استفاده کنند ، این است که معاملات را به طور کلی انجام دهید. با این حال ، با این رویکرد شما بسیاری از مزایایی را که معاملات می توانند ارائه دهند ، از دست نمی دهید. بسیاری از مدل های معامله جایگزین وجود دارد که برخی از خصوصیات اسید را آرام می کند ، در حالی که هنوز بسیاری از تضمین های قوی را برای ساختن برنامه های سازمانی قوی حفظ می کند. این مدل ها اغلب به عنوان "مدل های معامله گسترده" گفته می شوند و باید قبل از تصمیم گیری در مورد عدم استفاده از معاملات در نظر گرفته شوند.

در پروژه Narayana ، ما از سه مدل معامله گسترده پشتیبانی می کنیم."معاملات سطح بالا تو در تو" [Ref] ، "معاملات تو در تو" [Ref] و یک مدل مبتنی بر جبران خسارت مبتنی بر "ساگاس" [Ref]. در این سری از پست های وبلاگ ، من روی رویکرد مبتنی بر جبران خسارت تمرکز می کنم.

"تراکنش مبتنی بر جبران خسارت" چیست؟

سیستم های تراکنش معمولاً از یک پروتکل دو فازی برای دستیابی به اتمی بین شرکت کنندگان استفاده می کنند. این مورد هم برای تراکنش های ACID و هم برای مدل تراکنش های مبتنی بر جبران ما صدق می کند. در مرحله اول، هر یک از شرکت کنندگان در یک تراکنش ACID، تغییرات حالتی را که در طول معامله ایجاد شده است، بادوام خواهد کرد. این تغییرات حالت را می توان پس از مشخص شدن نتیجه تراکنش برگرداند یا بعداً متعهد شد. با این حال، شرکت کنندگان در یک تراکنش مبتنی بر غرامت، کمی متفاوت رفتار می کنند. در اینجا هر تغییر حالتی که در محدوده تراکنش ایجاد شده است، در طول (یا قبل از) مرحله اول انجام می شود. به منظور امکان "بازگشت"، یک کنترل کننده جبران خسارت در مرحله اول ثبت می شود. این اجازه می دهد تا در صورت شکست تراکنش، تغییرات حالت "لغو" شود.

این موضوع چه تأثیری بر ویژگی جداسازی تراکنش دارد؟

ویژگی Isolation یک تراکنش تعیین می کند که در صورت وجود چه تغییراتی در خارج از تراکنش، قبل از تکمیل آن قابل مشاهده است. برای تراکنش های ACID، ویژگی انزوا معمولاً بسیار قوی است و فروشندگان پایگاه داده درجاتی از آرامش را از طریق پیکربندی سطح جداسازی [REF] ارائه می دهند. با این حال، در یک تراکنش مبتنی بر غرامت، سطح انزوا کاملاً کاهش می یابد و اجازه می دهد واحدهای کار تکمیل شده و برای سایر تراکنش ها قابل مشاهده باشند، همانطور که تراکنش مبتنی بر غرامت فعلی پیشرفت می کند. مزیت این مدل این است که منابع پایگاه داده برای مدت زمان طولانی نگهداری نمی شوند. با این حال، جنبه منفی این است که این مدل فقط برای برنامه هایی قابل استفاده است که می توانند این سطح کاهش یافته ایزوله را تحمل کنند.

دو نمودار زیر نمونه ای را نشان می دهد، که در آن یک کلاینت در حال هماهنگ کردن فراخوانی ها برای چندین سرویس است که هر کدام یک پایگاه داده را به روزرسانی می کنند. نمودارها به منظور تمرکز بر سطوح مختلف جداسازی ارائه شده توسط ACID و تراکنش مبتنی بر جبران، ساده شده اند. این مثال همچنین فرض می کند که یک پایگاه داده توسط سرویس استفاده می شود، اما می تواند به همان اندازه برای منابع دیگر اعمال شود.

نمودار فوق یک نمودار توالی ساده شده از تعامل که در یک معامله اسیدی رخ می دهد را نشان می دهد. پس از شروع مشتری معامله (اسید) ، اولین سرویس را فراخوانی می کند. این سرویس باعث تغییر در یک پایگاه داده می شود و در این مرحله منابع پایگاه داده توسط معامله برگزار می شود. این مثال از قفل بدبینانه استفاده می کند. از قفل خوش بینانه استفاده شده است ، منابع نگهدارنده یا بانک اطلاعاتی می توانند تا مرحله آماده سازی به تأخیر بیفتند ، اما این می تواند منجر به خرابی بیشتر شود. مشتری سپس از سایر خدمات ، که به نوبه خود می توانند منابع دیگری را در اختیار داشته باشند ، فراخوانی می کند. بسته به تأخیر شبکه و ماهیت کار انجام شده توسط خدمات ، این کار می تواند مدتی طول بکشد. مدتی است که منابع DB هنوز توسط معامله برگزار می شود. اگر همه چیز خوب پیش برود ، مشتری درخواست می کند که مدیر معامله مرتکب معامله شود. مدیر معامله پروتکل تعهد دو فاز را آغاز می کند ، ابتدا با آماده سازی همه شرکت کنندگان و سپس اگر همه خوب پیش برود ، همه شرکت کنندگان را مرتکب می شود. تا زمانی که به شرکت کننده پایگاه داده گفته نمی شود متعهد شود ، این منابع بانک اطلاعاتی منتشر نمی شود.

از نمودار ، می بینید که چگونه در یک معامله اسیدی ، منابع DB را می توان برای مدت زمان طولانی نسبی برگزار کرد. همچنین ، با فرض اینکه این سرویس مایل به تصمیم اکتشافی نیست ، این مدت فراتر از کنترل خدمات است. باید منتظر بماند تا از نتیجه پروتکل مطلع شود ، که مشمول تأخیرهای معرفی شده توسط سایر شرکت کنندگان است.

نمودار فوق یک نمودار توالی ساده از ارتباطات را نشان می دهد که در یک معامله مبتنی بر جبران خسارت رخ می دهد. مشتری یک معامله جدید (مبتنی بر جبران خسارت) را آغاز می کند و سپس اولین سرویس را فراخوانی می کند. این سرویس سپس به روزرسانی به پایگاه داده ، که مرتکب Imediatlly است ، در یک معامله اسید جداگانه و جداگانه ارسال می کند. در این مرحله (در نمودار نشان داده نشده است) این سرویس به مدیر معامله اطلاع می دهد که کار خود را به اتمام رسانده است ، و این باعث می شود مدیر معامله نتیجه کار این شرکت کننده را به ذخیره دوام به همراه جزئیات کنترل کننده جبران خسارت و هر ایالت ثبت کند. برای انجام جبران خسارت لازم است. می توان تعهد اسید را به تأخیر انداخت تا اینکه پس از ورود به سیستم جبران خسارت (به اینجا مراجعه کنید [Ref]) ، این یک پنجره خرابی را از بین می برد که در آن می تواند نتیجه غیر اتمی رخ دهد.

مشتری اکنون از سایر سرویس هایی استفاده می کند که در این مثال به طور مشابه با اولین سرویس رفتار می کنند. سرانجام ، مشتری می تواند مدیر معامله را ببندد (متعهد) یا لغو (بازپرداخت) معامله مبتنی بر جبران خسارت. در مورد لغو ، مدیر معامله ، اقدام جبران خسارت را با هر یک از شرکت کنندگان که قبلاً برخی کارها را انجام داده بود ، فراخوانی می کند. در این مثال ، عمل جبران کننده باعث می شود تا در یک معامله کوتاه اسید کوتاه و نسبی ، پایگاه داده را به روز کنید. همچنین در صورت بسته شدن معامله مبتنی بر جبران خسارت ، می توان به این سرویس اطلاع داده شد. ما موقعیت هایی را پوشش خواهیم داد که بعداً در این سری مفید باشد. اطلاع رسانی (نزدیک/جبران) تا زمانی که توسط سرویس تأیید شود ، دوباره انجام می شود. اگرچه این برای قابلیت اطمینان مناسب است ، اما این امر مستلزم این است که منطق دستگیرها بی پروا باشند.

از نمودار می بینید که مدت زمان نگهداری منابع DB ، بسیار کاهش می یابد. این با هزینه انزوای آرام است (به نشانگر "تغییرات قابل مشاهده" مراجعه کنید). با این حال ، در سناریوهایی که جبران خسارت نادر است ، انزوای آرام می تواند نگرانی کمی داشته باشد زیرا معمولاً تغییرات قابل مشاهده معتبر است.

همچنین می توان با علامت گذاری به عنوان آزمایشی در مرحله اول ، این از دست دادن انزوا را کاهش داد و سپس تغییر را به عنوان تأیید/لغو در مرحله دوم نشان داد. به عنوان مثال ، تغییر اولیه می تواند یک صندلی در هواپیما را به عنوان رزرو نشان دهد. بسته به نتیجه معامله ، این صندلی بعداً می تواند به صورت رزرو شده منتشر یا مشخص شود. در اینجا ما برای نگه داشتن منابع سطح برنامه (در این حالت صندلی) ، منابع سطح پایگاه داده را معامله کرده ایم. این رویکرد بعداً در این سریال با جزئیات بیشتری پوشش داده شده است.

چه چیزی در پست های بعدی آمده است؟

سه پست زیر هر یک بر روی مجموعه خاصی از موارد استفاده متمرکز خواهد شد که در آن معاملات مبتنی بر جبران خسارت می تواند مناسب تر از معاملات اسیدی باشد. در هر قسمت ، من یک مثال کد را با استفاده از آخرین تکرار API جدید ما برای معاملات مبتنی بر جبران خسارت ارائه می دهم (برای اولین بار در [Ref] معرفی شده است).

قسمت 2: کار غیر متعادل. این بخش موقعیت هایی را در بر می گیرد که شما نیاز به هماهنگی چندین منبع غیر تعامل ، مانند ارسال ایمیل یا استناد به یک سرویس شخص ثالث دارید.

قسمت 3: معاملات توزیع شده متقابل: این قسمت سناریویی را در آن توزیع می کند که معامله توزیع می شود و به طور بالقوه از چندین حوزه تجاری عبور می کند.

قسمت 4: معاملات طولانی مدت. این قسمت معاملات را شامل می شود که دوره های طولانی را پشت سر می گذارد و نشان می دهد که چگونه می توان معامله را ادامه داد حتی اگر برخی از کارها از بین بروند.

در قسمت پنجم ، وضعیت پشتیبانی ما برای معاملات مبتنی بر جبران خسارت را پوشش می دهم و نقشه راه را برای کارهای آینده خود ارائه می دهم.

جبران معاملات: وقتی اسید خیلی زیاد است.

قسمت 2: منابع غیر تعامل

مقدمه

در قسمت اول [Ref] در این سری توضیح دادم که چرا معاملات اسیدی همیشه مناسب نیستند. من همچنین معاملات مبتنی بر جبران خسارت را به عنوان جایگزینی احتمالی برای معاملات اسید معرفی کردم. در این پست من به موقعیت هایی می پردازم که برنامه برای هماهنگی چندین منبع غیر متعادل و نشان می دهد که چگونه می توان از معامله مبتنی بر جبران خسارت برای حل این مشکل استفاده کرد.

به خاطر این بحث ، من یک منبع معامله ای را به عنوان موردی تعریف می کنم که می تواند در یک پروتکل دو فاز شرکت کند و از این رو می تواند تهیه شود و بعداً متعهد یا برگشت. به عنوان مثال ، پایگاه داده های قابل دسترسی یا صف پیام ، منابع معامله ای در نظر گرفته می شوند. در مقابل ، یک منبع غیر متعاقب آن موردی است که این تسهیلات را ارائه نمی دهد. به عنوان مثال ، ارسال ایمیل یا چاپ یک چک نمی تواند به راحتی در این پروتکل دو فاز شرکت کند. خدمات شخص ثالث همچنین می تواند در یک معامله اسیدی هماهنگ باشد. حتی اگر این سرویس ها با معاملات اسیدی اجرا شوند ، ممکن است اجازه شرکت در هر معامله موجود را نداشته باشند.

معامله مبتنی بر جبران خسارت می تواند مناسب برای این شرایط باشد. کار غیر متعادل می تواند در محدوده معامله مبتنی بر جبران خسارت انجام شود. با توجه به اینکه یک کنترل کننده جبران خسارت ثبت شده است ، در صورت نیاز به معامله مبتنی بر جبران خسارت ، می تواند بعداً از بین برود. به عنوان مثال ، کنترل کننده جبران خسارت برای ارسال ایمیل می تواند ارسال ایمیل دوم باشد که از گیرنده بخواهد که از ایمیل اول چشم پوشی کند. چاپ یک چک را می توان با لغو چک و اطلاع دهنده گیرنده لغو جبران کرد.

همچنین می توان با هماهنگی منابع معامله ای و غیر متعادل در یک معامله مبتنی بر جبران خسارت هماهنگ شد. در اینجا برنامه فقط نیاز به ایجاد دستگیرنده های جبران خسارت برای منابع غیر تعامل دارد. اگر فقط یک منبع غیر تعامل دارید ، می توانید از یک معامله اسیدی با آخرین منبع بهینه سازی تعهد (LRCO) استفاده کنید ، اما در صورت داشتن چندین منبع غیر متعادل ، این رویکرد توصیه نمی شود.

به طور خلاصه: اگر خود را پیدا کردید که نیاز به هماهنگی چندین منبع غیر تعامل داشته باشید ، باید از جبران خسارت استفاده کنید.

مثال کد

در این مثال کد ، ما یک سرویس ساده داریم که توسط یک برنامه Ecomerce برای فروش کتاب استفاده می شود. و همچنین به روزرسانی در منابع معامله ای ، مانند یک بانک اطلاعاتی ، همچنین نیاز به ارسال ایمیلی برای اطلاع مشتری به مشتری مبنی بر اینکه سفارش داده شده است.

کلاس فوق نشان دهنده خدمات کتاب است. روش "BuyBook" به روزرسانی های پایگاه داده را هماهنگ می کند و از طریق ایمیل به مشتری اطلاع می دهد. روش "Buybook" با "chompensatable" حاشیه نویسی شده است. پردازش این حاشیه نویسی تضمین می کند که هنگام استفاده از روش ، معامله مبتنی بر جبران خسارت انجام می شود. این حاشیه نویسی به طور مشابه با حاشیه نویسی transactional پردازش می شود (جدید به JTA 1. 2). تفاوت اصلی این است که به جای معامله JTA (اسید) با یک معامله مبتنی بر جبران خسارت کار می کند. یک RuntimeException Uncaught (یا زیر کلاس) باعث لغو معامله می شود و هر کار تکمیل شده جبران می شود. باز هم ، این رفتار مبتنی بر رفتار رسیدگی به معامله Transactional در JTA 1. 2 است.

به خاطر کوتاه بودن ، من تماس های برای به روزرسانی سایر منابع معامله را حذف کرده ام. قسمت 3 این سری ارتباطات با معاملات اسید JTA را نشان می دهد.

این کلاس کار مورد نیاز برای اطلاع مشتری را انجام می دهد. در این حالت ارسال ایمیل را شبیه سازی می کند. در صورت عدم موفقیت معامله ، روش "NotifyCustomerO f-Purchase" می تواند جبران شود. این با استفاده از حاشیه نویسی "جبران خسارت" پیکربندی شده است. این حاشیه نویسی مشخص می کند که از کدام کلاس برای جبران کار انجام شده در روش استفاده می شود. برای اینکه این جبران خسارت امکان پذیر باشد ، به اطلاعات کلیدی در مورد کار تکمیل شده در دسترس خواهد بود. در این حالت مورد سفارش داده شده و آدرس مشتری. این داده ها در یک لوبیای مدیریت شده CDI ، "OrderData" ذخیره می شود ، که همانطور که بعداً خواهیم دید ، در کنترل کننده جبران خسارت نیز تزریق می شود.

این لوبیای مدیریت شده نشان دهنده وضعیتی است که توسط کنترل کننده جبران خسارت برای لغو کار لازم است. نکته کلیدی که در اینجا باید به آن توجه کرد این است که لوبیا با @CompensationScoped حاشیه نویسی شده است. این محدوده بسیار شبیه به حاشیه نویسی @TransactionScoped (جدید در JTA 1. 2) است. این حاشیه نویسی تضمین می کند که چرخه حیات bean به تراکنش جاری در حال اجرا گره خورده است. در این مورد، چرخه عمر تراکنش مبتنی بر جبران خسارت، اما در مورد @TransactionScoped به چرخه عمر تراکنش JTA گره خورده است. لوبیای @CompensationScoped نیز در گزارش تراکنش سریالی خواهد شد، به طوری که در مواردی که کنترل کننده جبران نیاز به فراخوانی در زمان بازیابی [REF] باشد، در دسترس باشد.

این کلاس کنترل کننده جبران خسارت را پیاده سازی می کند. برای مثال ما به سادگی جزئیات سفارش را از OrderData bean تزریق می کند و سپس برای مشتری ارسال می کند و ایمیل می فرستد و به آنها اطلاع می دهد که سفارش شکست خورده است.

خلاصه

در این پست وبلاگ توضیح دادم که چرا هماهنگ کردن منابع غیرمعمولی در یک تراکنش ACID دشوار است و نشان دادم که چگونه می توان از تراکنش مبتنی بر جبران خسارت برای حل این مشکل استفاده کرد.

بخش 3، از این مجموعه، به تراکنش های توزیع شده بین دامنه ای می پردازد: در اینجا نشان خواهم داد که تراکنش های ACID همیشه انتخاب خوبی برای سناریوهایی که تراکنش در آن توزیع می شود، و به طور بالقوه از چندین دامنه تجاری عبور می کنند، نیستند. من نشان خواهم داد که چگونه می توان از یک تراکنش مبتنی بر جبران خسارت برای ارائه راه حل بهتر استفاده کرد.

جبران معاملات: وقتی اسید خیلی زیاد است

بخش 3: تراکنش های توزیع شده بین دامنه ای

مقدمه

در بخش اول [REF] در این مجموعه توضیح دادم که چرا تراکنش های ACID همیشه مناسب نیستند. من همچنین تراکنش های مبتنی بر جبران خسارت را به عنوان جایگزین احتمالی برای تراکنش های ACID معرفی کردم. در این پست نشان خواهم داد که چگونه تراکنش های مبتنی بر جبران خسارت می توانند مناسب تر از تراکنش های ACID برای برنامه های کاربردی توزیع شده ای باشند که از شبکه های تأخیر بالا عبور می کنند یا دامنه های تجاری متعددی را در بر می گیرند.

هنگامی که برنامه شما توزیع می شود و سیستم های بیشتری درگیر می شوند، به ناچار احتمال شکست را افزایش می دهید. بسیاری از این خرابی ها را می توان با استفاده از یک تراکنش ACID توزیع شده تحمل کرد. با این حال، تراکنش ACID را می توان برای برنامه های کاربردی توزیع شده خاص غیرعملی دانست. اولین دلیل این امر این است که تراکنش های توزیع شده، که از شبکه های با تأخیر بالا (مانند اینترنت) عبور می کنند، می توانند زمان نسبتاً طولانی تری برای اجرا داشته باشند. همانطور که در قسمت 1 [REF] نشان دادم، افزایش زمان برای اجرای تراکنش ACID می تواند تأثیرات منفی بر برنامه شما داشته باشد. به عنوان مثال، نگهداری منابع پایگاه داده برای دوره های طولانی می تواند به طور قابل توجهی توان عملیاتی برنامه شما را کاهش دهد. دلیل دوم به دلیل اتصال شدید بین شرکت کنندگان در معامله است. این جفت سخت به این دلیل رخ می دهد که هماهنگ کننده ریشه تراکنش در نهایت تمام منابع تراکنش را از طریق پروتکل 2PC هدایت می کند. بنابراین، پس از آماده شدن، یک منبع تراکنشی باید یا یک تصمیم اکتشافی (بد) بگیرد یا منتظر بماند تا هماهنگ کننده ریشه آن را از نتیجه مطلع کند. اگر برنامه توزیع شده شما در یک حوزه تجاری واحد قرار داشته باشد که در آن شما کنترل همه طرفین را در اختیار دارید، این اتصال محکم ممکن است قابل قبول باشد. با این حال، احتمال کمتری دارد که برای برنامه های کاربردی توزیع شده که دامنه های تجاری متعددی را در بر می گیرند، قابل قبول باشد.

معاملات مبتنی بر جبران خسارت می تواند راه حل بهتری برای این سناریوها باشد. همانطور که در قسمت 1 [REF] نشان دادم، تراکنش های مبتنی بر جبران خسارت می توانند برای تراکنش های طولانی تر مناسب تر باشند، زیرا نیازی به نگه داشتن منابع پایگاه داده تا پایان تراکنش ندارند. از تراکنش های مبتنی بر جبران خسارت نیز می توان برای جدا کردن منابع بک اند از هماهنگ کننده تراکنش استفاده کرد. این را می توان با تقسیم دو مرحله پروتکل به عملیات تجاری انتزاعی، مانند کتاب/لغو، انجام داد. عملیات "کتاب" یک به روز رسانی به پایگاه داده برای ایجاد رزرو انجام می دهد. از آنجایی که این به روزرسانی بلافاصله انجام می شود، هیچ پیوند محکمی بین منابع پایگاه داده و هماهنگ کننده تراکنش وجود ندارد. اگر تراکنش مبتنی بر غرامت نیاز به لغو داشته باشد، عملیات لغو توسط کنترل کننده جبران خسارت فراخوانی می شود.

مثال کد

در این مثال ما به یک مثال ساده رزرو سفر نگاه می کنیم، که در آن یک مشتری یک هتل و تاکسی را با خدمات از راه دور رزرو می کند، در یک تراکنش مبتنی بر غرامت. این سرویس های راه دور در حوزه های مختلف تجاری زندگی می کنند و از طریق اینترنت فراخوانی می شوند.

این کد بخشی از برنامه مشتری را تشکیل می دهد. روش "makebooking" با "compensatable" حاشیه نویسی می شود که تضمین می کند که این روش در یک معامله مبتنی بر جبران خسارت فراخوانی می شود. این روش دو سرویس وب را فراخوانی می کند. این خدمات وب از WS-BA [Ref] پشتیبانی می کنند ، بنابراین معامله به طور شفاف بر روی این تماس ها توزیع می شود.

در اینجا کد سرویس وب هتل است. و همچنین حاشیه نویسی های معمول JAX-WS که انتظار دارید (برخی از آنها برای کوتاه بودن حذف شده اند) ، یادداشت های اضافی برای مدیریت معاملات وجود دارد. اولین مورد compensatable (اجباری) است. این تضمین می کند که این روش در محدوده معامله مبتنی بر جبران خسارت فراخوانی می شود. دومین حاشیه نویسی (compensatewith) کنترل کننده جبران خسارت را ارائه می دهد ، که باید از قسمت 2 در این سری با آنها آشنا باشید. سومین حاشیه نویسی (completewith) ممکن است برای شما جدید باشد. این حاشیه نویسی یک کنترل کننده را فراهم می کند که در صورت موفقیت در پایان معامله استناد می شود. این امر به برنامه اجازه می دهد تا هنگامی که می داند معامله جبران نمی شود ، تغییرات نهایی را ایجاد کند. امیدوارم که با بحث در مورد این مثال ، نیاز به این ویژگی روشن تر شود. سرانجام ، این مثال از حاشیه نویسی JTA 1. 2Transactional برای شروع معامله جدید JTA استفاده می کند. این معامله برای به روزرسانی در پایگاه داده استفاده می شود و در صورت تکمیل موفقیت آمیز روش "MakeBooking" ، مرتکب می شود. معامله JTA در صورتی که یک BookingException (به ویژگی Rollbackon مراجعه کنید) یا یک RuntimeException (یا یک زیر کلاس) پرتاب می شود ، بازپرداخت خواهد شد.

بنابراین ، چرا معامله JTA در پایان این روش متعهد می شود حتی اگر معامله مبتنی بر جبران خسارت هنوز در حال انجام است؟

این کار برای کاهش میزان زمانی که سرویس بر روی منابع پایگاه داده انجام می دهد انجام می شود. این برنامه به سادگی می تواند رزرو را به پایگاه داده اضافه کند ، اما این امکان وجود دارد که در آینده در آینده نیاز به لغو داشته باشد. بنابراین در این مثال ، برنامه فقط رزرو را در انتظار است. بنابراین ، هر معامله دیگری که وضعیت جدول رزرو را می خواند ، می بیند که این رزرو خاص آزمایشی است. به یاد داشته باشید ، با استفاده از یک معامله مبتنی بر جبران خسارت ، ما انزوا آرام داریم و این یکی از راه هایی است که می توان برنامه را برای تحمل این امر اصلاح کرد.

همانطور که در بالا ذکر شد ، تأیید کننده یک پاسخ به تماس را ارائه می دهد که هنگام انجام معاملات مبتنی بر جبران خسارت با موفقیت انجام می شود. در این مثال ، کنترل کننده تأیید یک معامله جدید JTA را آغاز می کند و سپس بانک اطلاعاتی را به روز می کند تا رزرو را به صورت نهایی نشان دهد.

به همین ترتیب ، ما همچنین یک کنترل کننده جبران خسارت داریم که معامله جدید JTA را شروع می کند که رزرو را لغو می کند.

در این مثال ، ما در اصل تجارت بین 2 معاملات JTA کوتاه تر را انجام می دهیم ، با انزوا آرام (در این مثال) به جای 1 معامله JTA طولانی تر با انزوا قوی تر (اگر از معامله JTA توزیع شده استفاده می کردیم). ما همچنین برای ایجاد انزوای آرام ، نیاز به ایجاد تغییر در برنامه داشتیم. این یک تجارت معقول است که تا حد زیادی به کاربرد و نیازهای عملکرد شما بستگی دارد.

همچنین شایان ذکر است که میانه نرم افزار می تواند (ما هنوز این کار را اجرا نمی کنیم) با اطمینان از معامله مبتنی بر جبران خسارت و معامله JTA به هم پیوند بزنند. این کار را با تهیه معامله JTA هنگامی که روش تکمیل می شود ، انجام می دهد ، اما مرتکب آن می شود تا زمانی که کنترل کننده جبران خسارت به ورود به سیستم معامله وارد شود. این تضمین می کند که کار فقط در صورتی انجام می شود که بعداً در صورت عدم موفقیت جبران شود. دعوت از جبران خسارت و تأییدیه نیز قابل اعتماد است زیرا تا زمانی که با موفقیت کامل شوند ، بارها و بارها مورد استفاده قرار می گیرند. بنابراین ، مهم است که پیاده سازی های آنها idempotent باشد.

جبران معاملات: وقتی اسید خیلی زیاد است

قسمت 4: معاملات طولانی مدت

مقدمه

در قسمت اول [Ref] ، من توضیح دادم که چگونه معاملات اسیدی می تواند تأثیر منفی بر برنامه هایی داشته باشد که معاملات آنها می تواند مدت زمان نسبتاً طولانی برای اجرای آن داشته باشد. علاوه بر این ، یکی دیگر از مسئله بالقوه در معاملات اسیدی این است که عدم موفقیت یک واحد می تواند باعث شود کل معامله به عقب برگردد. این مسئله برای معاملات کوتاه مدت کمتر مسئله ای است ، زیرا کار قبلاً موفق می تواند به سرعت دوباره انجام شود. با این حال ، برای معاملات طولانی مدت ، این کار که قبلاً انجام شده است ممکن است قابل توجه باشد و در صورت نیاز به بازگشت به زباله های زیادی منجر می شود. در این پست ، من نشان خواهم داد که چگونه یک معامله مبتنی بر جبران خسارت می تواند مناسب تر برای معاملات طولانی مدت باشد.

معامله مبتنی بر جبران خسارت می تواند از چندین معاملات اسید کوتاه مدت تشکیل شود. پس از اتمام هر معامله ، قفل های منابع موجود در آن را آزاد می کند ، و این امکان را می دهد تا سایر معاملات ، نیاز به این منابع را انجام دهند. اقدامات جبران خسارت برای هر معامله اسیدی ثبت شده است و در صورت نیاز به قطع شدن کل معامله مبتنی بر جبران خسارت ، می تواند برای خنثیسازی هر کار انجام شود. علاوه بر این ، در صورت عدم موفقیت یکی از این معاملات اسیدی کوتاه مدت ، می توان یک جایگزین را پیدا کرد و مانع از عدم موفقیت کل معامله شد. این اجازه می دهد تا پیشرفت رو به جلو حاصل شود. با ایجاد معامله مبتنی بر جبران خسارت به عنوان چندین واحد کار ، شما همچنین می توانید با پیشرفت معامله مبتنی بر جبران خسارت ، واحدهای خاص را به صورت انتخابی (جبران) انتخاب کنید. یک مثال ساده باید به روشن شدن این ایده ها کمک کند.

به عنوان مثال ، یک سناریوی رزرو سفر کنید. ما با رزرو پرواز شروع می کنیم. سپس ما سعی می کنیم یک تاکسی رزرو کنیم ، اما این کار ناکام است. در این مرحله ما نمی خواهیم پرواز را جبران کنیم زیرا ممکن است دفعه بعد که سعی می کنیم کاملاً رزرو شود. بنابراین ما سعی می کنیم یک تاکسی جایگزین پیدا کنیم که در این مثال موفق می شود. بعداً ، در معامله مبتنی بر جبران خسارت ، ممکن است پرواز ارزان تری پیدا کنیم ، در این صورت می خواهیم پرواز اصلی را ضمن نگه داشتن تاکسی و پرواز ارزان تر لغو کنیم. در این حالت ما اهداف خود را به مدیر معامله اطلاع می دهیم که اطمینان حاصل می کند که پرواز گران تر با اتمام معامله مبتنی بر جبران خسارت جبران می شود.

مثال کد

در این مثال ، من از قسمت 3 از قسمت 3 در این سری به عنوان مثال نمایندگی سفر می کنم. در اینجا من نشان خواهم داد که چگونه عدم تکمیل یک واحد کار لازم نیست که کل معامله مبتنی بر جبران خسارت قطع شود.

برای این مثال ، می توانید تصور کنید که هتل و خدمات تاکسی به طور مشابه با هتل در قسمت 3 اجرا می شوند.

روش makeBooking با @Compensatable حاشیه نویسی شده است، که تضمین می کند که روش در یک تراکنش مبتنی بر جبران فراخوانی می شود. این روش با رزرو هتل شروع می شود. اگر این کار انجام نشد، ما BookingException را که باعث لغو تراکنش مبتنی بر جبران خسارت می شود، مدیریت نمی کنیم. سپس به رزرو تاکسی می رویم. اگر این رزرو خاص با شکست مواجه شد، ما BookingException را می گیریم و یک شرکت تاکسی جایگزین را امتحان می کنیم. از آنجایی که سرویس تاکسی فوراً از کار افتاد، می دانیم که باید (الزام استفاده از این API است) هر یک از کارهایش را لغو می کرد. بنابراین می توانیم معامله مبتنی بر غرامت را شکست دهیم یا در این مورد یک شرکت تاکسی جایگزین را امتحان کنیم. نکته مهمی که در اینجا باید به آن توجه داشت این است که ما هنوز هتل را رزرو کرده ایم و واقعاً نمی خواهیم این رزرو را از دست بدهیم زیرا ممکن است دفعه بعد که سعی کنیم هتل کاملاً رزرو شود. سپس کد به تلاش برای یک شرکت تاکسی جایگزین می رود. اگر این رزرو ناموفق باشد، ما هیچ گزینه ای نداریم جز اینکه کل معامله را لغو کنیم زیرا جایگزین دیگری نداریم.

نتیجه

در این پست وبلاگ، من نشان دادم که چگونه یک تراکنش مبتنی بر جبران خسارت می تواند مناسب تراکنش های طولانی مدت باشد. در قسمت بعدی وضعیت API خود را برای تراکنش های مبتنی بر غرامت مورد بحث قرار می دهم.