با استفاده از حافظه معامله نرم افزاری در Quarkus

حافظه تراکنش نرم افزاری (STM) از اواخر دهه 1990 در محیط های تحقیقاتی وجود دارد و اخیراً در محصولات و زبانهای مختلف برنامه نویسی ظاهر شده است. ما به تمام جزئیات پشت STM نمی پردازیم اما خواننده علاقه مند می تواند به این مقاله نگاه کند. با این حال ، کافی است که بگوییم STM رویکردی را برای توسعه برنامه های معامله ای در یک محیط بسیار همزمان با برخی از ویژگی های مشابه معاملات اسیدی ، که احتمالاً قبلاً از طریق JTA استفاده کرده اید ، ارائه می دهد. مهمتر از همه ، خاصیت دوام در اجرای STM آرام (حذف شده) یا حداقل اختیاری است. این وضعیت JTA نیست ، جایی که تغییرات حالت با دوام با یک پایگاه داده رابطه ای که از استاندارد X/Open XA پشتیبانی می کند ، بادوام می شود.

توجه داشته باشید که اجرای STM ارائه شده توسط Quarkus بر اساس اجرای Narayana STM است. این سند به معنای جایگزینی برای مستندات آن پروژه نیست ، بنابراین ممکن است بخواهید برای جزئیات بیشتر به آن نگاه کنید. با این حال ، ما سعی خواهیم کرد تا بیشتر در مورد چگونگی ترکیب برخی از قابلیت های کلیدی در Quarkus هنگام توسعه برنامه های کاربردی بومی Kubernetes و میکروسرویس ها تمرکز کنیم.

چرا از STM با Quarkus استفاده می کنیم؟

حالا ممکن است هنوز از خود بپرسید "چرا به جای JTA STM؟"یا "مزایایی برای STM که من از JTA دریافت نمی کنم چیست؟"بیایید سعی کنیم به آن سؤالات یا سؤالات مشابه پاسخ دهیم ، با تمرکز خاصی بر این که چرا فکر می کنیم آنها برای برنامه های بومی Quarkus ، MicroService و Kubernetes عالی هستند. بنابراین به ترتیب خاصی ...

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

اشیاء STM حالت دارند، اما نیازی به ماندگاری (بادوام) ندارند. در واقع رفتار پیش‌فرض این است که اشیایی که در حافظه تراکنش مدیریت می‌شوند، فرار باشند، به‌طوری‌که اگر سرویس یا میکروسرویسی که در آن استفاده می‌شود از کار بیفتد یا در جای دیگری ایجاد شود، مثلاً توسط یک زمان‌بندی، تمام حالت‌های حافظه از بین رفته و اشیاءاز صفر شروع کناما مطمئناً شما این و بیشتر را با JTA (و یک دیتا استور مناسب تراکنش) دریافت می‌کنید و نیازی نیست نگران راه‌اندازی مجدد برنامه خود باشید؟نه کاملا. در اینجا یک مبادله وجود دارد: ما در حال حذف حالت پایدار و سربار خواندن و سپس نوشتن (و همگام سازی) در ذخیره‌گاه داده در طول هر تراکنش هستیم. این باعث می‌شود به‌روزرسانی‌ها در حالت (فرار) بسیار سریع باشند، اما همچنان از مزایای به‌روزرسانی‌های اتمی در چندین شی STM بهره‌مند می‌شوید (مثلاً اشیایی که تیم شما نوشته است و سپس اشیایی را که از تیم دیگری به ارث برده‌اید فراخوانی می‌کند و از آنها می‌خواهد به‌روزرسانی‌های «همه یا هیچ» را انجام دهند.) و همچنین سازگاری و انزوا در حضور نخ ها/کاربران همزمان (متداول در معماری های میکروسرویس های توزیع شده). علاوه بر این، لازم نیست همه برنامه‌های حالت‌دار بادوام باشند - حتی زمانی که از تراکنش‌های JTA استفاده می‌شود، این امر استثنا است و نه قاعده. و همانطور که بعداً خواهید دید، از آنجا که برنامه‌ها می‌توانند به صورت اختیاری تراکنش‌ها را شروع و کنترل کنند، می‌توان میکروسرویس‌هایی ساخت که می‌توانند تغییرات حالت را لغو کنند و مسیرهای جایگزین را امتحان کنند.

یکی دیگر از مزایای STM ترکیب پذیری و ماژولار بودن است. می‌توانید اشیاء/سرویس‌های کوارکوس همزمان بنویسید که به راحتی با هر سرویس دیگری که با استفاده از STM ساخته شده است، ترکیب شوند، بدون اینکه جزئیات نحوه پیاده‌سازی اشیاء/سرویس‌ها را فاش کنید. همانطور که قبلاً بحث کردیم، این توانایی برای نوشتن اشیایی که با آن تیم‌های دیگر نوشته‌اید ممکن است هفته‌ها، ماه‌ها یا سال‌ها زودتر نوشته شده باشد و دارای ویژگی‌های A، C و I باشد، می‌تواند بسیار سودمند باشد. علاوه بر این، برخی از پیاده‌سازی‌های STM، از جمله مواردی که کوارکوس استفاده می‌کند، از تراکنش‌های تودرتو پشتیبانی می‌کنند و این امکان را فراهم می‌کند که تغییرات ایجاد شده در چارچوب یک تراکنش تودرتو (زیر) بعداً توسط تراکنش مادر بازگردانده شود.

اگرچه حالت پیش‌فرض برای وضعیت شی STM فرار است، اما می‌توان پیاده‌سازی STM را به گونه‌ای پیکربندی کرد که وضعیت یک شی بادوام باشد. اگرچه می‌توان Narayana را به گونه‌ای پیکربندی کرد که از ذخیره‌گاه‌های داده پشتیبان مختلف، از جمله پایگاه‌های داده رابطه‌ای استفاده شود، پیش‌فرض سیستم فایل سیستم عامل محلی است، به این معنی که نیازی به پیکربندی هیچ چیز دیگری با Quarkus مانند پایگاه داده ندارید.

بسیاری از پیاده‌سازی‌های STM اجازه می‌دهند که «اشیاء زبان قدیمی ساده» با تغییرات اندک یا بدون تغییر در کد برنامه، از STM آگاه شوند. می‌توانید برنامه‌ها را بدون اینکه بخواهید از STM آگاه باشند، بسازید، آزمایش کنید و اجرا کنید و بعداً در صورت لزوم و بدون نیاز به توسعه زیاد، آن قابلیت‌ها را اضافه کنید.

ساخت برنامه های STM

همچنین یک مثال کاملاً کار شده در QuickStarts وجود دارد که می‌توانید با شبیه‌سازی مخزن Git به آن دسترسی پیدا کنید: git clone https://github. com/quarkusio/quarkus-quickstarts. git یا با دانلود یک آرشیو. به دنبال مثال نرم افزار-تراکنشی-حافظه-شروع سریع باشید. این به درک اینکه چگونه می توانید برنامه های کاربردی STM-aware با Quarkus بسازید کمک می کند. با این حال، قبل از انجام این کار، چند مفهوم اساسی وجود دارد که باید آنها را پوشش دهیم.

توجه داشته باشید، همانطور که خواهید دید، STM در Quarkus برای تعریف رفتارها به تعدادی حاشیه نویسی متکی است. فقدان این حاشیه‌نویسی‌ها باعث می‌شود پیش‌فرض‌های معقولی در نظر گرفته شوند، اما برای توسعه‌دهنده مهم است که بفهمد این موارد ممکن است چیست. لطفاً برای جزئیات بیشتر در مورد تمام حاشیه نویسی هایی که Narayana STM ارائه می دهد، به دفترچه راهنمای نارایانا STM و راهنمای حاشیه نویسی STM مراجعه کنید.

این فناوری پیش نمایش در نظر گرفته می شود.

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

برای فهرست کامل وضعیت‌های احتمالی، ورودی سؤالات متداول ما را بررسی کنید.

راه اندازی آن

برای استفاده از پسوند، آن را به عنوان یک وابستگی در فایل ساخت خود قرار دهید:

تعریف کلاس های آگاه از STM

برای اینکه زیرسیستم STM دانشی در مورد اینکه کدام کلاس ها باید در چارچوب حافظه تراکنشی مدیریت شوند، داشته باشد، لازم است حداقل سطح ابزار دقیق را ارائه دهد. این امر با طبقه‌بندی کلاس‌های STM-aware و STM-unaware از طریق یک مرز رابط اتفاق می‌افتد. به طور خاص، تمام اشیاء آگاه از STM باید نمونه‌هایی از کلاس‌هایی باشند که از رابط‌هایی به ارث می‌برند که خودشان حاشیه‌نویسی شده‌اند تا آنها را به عنوان STM-aware شناسایی کنند. هر شیء دیگری (و کلاس‌های آن‌ها) که از این قانون پیروی نمی‌کنند، توسط زیرسیستم STM مدیریت نمی‌شوند و از این رو، برای مثال، هیچ یک از تغییرات حالت آن‌ها برگردانده نمی‌شود.

حاشیه نویسی خاصی که رابط های برنامه STM-aware باید استفاده کنند org. jboss. stm. annotations. Transactional است. مثلا:

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

به عنوان مثال، با استفاده از حاشیه‌نویسی @ReadLock در متد getNumberOfBookings، می‌توانیم به زیرسیستم STM بگوییم که هیچ تغییر حالتی در این شیء زمانی که در حافظه تراکنشی استفاده می‌شود، رخ نخواهد داد. همچنین، حاشیه‌نویسی @NotState به سیستم می‌گوید در زمان انجام یا لغو تراکنش‌ها، TimeCalled را نادیده بگیرد، بنابراین این مقدار فقط به دلیل کد برنامه تغییر می‌کند.

لطفاً برای جزئیات نحوه اعمال کنترل دقیق‌تر بر رفتار تراکنشی اشیایی که رابط‌های علامت‌گذاری شده با @Transactional را پیاده‌سازی می‌کنند، به راهنمای نارایانا مراجعه کنید.

ایجاد اشیاء STM

به زیرسیستم STM باید گفته شود که کدام اشیاء را باید مدیریت کند. اجرای STM کوارکوس (معروف به نارایانا) این کار را با ارائه کانتینرهایی از حافظه تراکنشی انجام می دهد که این نمونه های شی در آن قرار دارند. تا زمانی که یک شی در یکی از این کانتینرهای STM قرار نگیرد، نمی‌توان آن را در تراکنش‌ها مدیریت کرد و هرگونه تغییر حالت دارای ویژگی‌های A، C، I (یا حتی D) نخواهد بود.

توجه داشته باشید ، اصطلاح "کانتینر" در سالهای اجرای STM قبل از رسیدن ظروف لینوکس تعریف شده است. ممکن است استفاده به خصوص در یک محیط بومی Kubernetes مانند Quarkus گیج کننده باشد ، اما امیدوارم خواننده بتواند نقشه برداری ذهنی را انجام دهد.

کانتینر پیش فرض STM (org. jboss. stm. container) پشتیبانی از اشیاء فرار را فراهم می کند که فقط در همان نمونه میکروسرویس/JVM می توانند بین موضوعات به اشتراک گذاشته شوند. هنگامی که یک شیء آگاه STM در داخل ظرف قرار می گیرد ، دسته ای را که از طریق آن باید از آن شی استفاده شود ، در آینده باز می گرداند. استفاده از این دسته مهم است زیرا ادامه دسترسی به شی از طریق مرجع اصلی به زیر سیستم STM اجازه نمی دهد دسترسی و کنترل حالت و همزمانی را ردیابی کند.

تعریف مرزهای معامله

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

رویکرد اعلانی

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

رویکرد برنامه ای

برنامه می تواند قبل از دسترسی به روشهای STM به صورت برنامه ای معامله را شروع کند:

معاملات توزیع شده

به اشتراک گذاشتن معامله بین چندین سرویس امکان پذیر است اما در حال حاضر فقط یک مورد استفاده پیشرفته است و در صورت نیاز به این رفتار باید از اسناد Narayana مشاوره شود. به طور خاص ، STM هنوز از ویژگی های شرح داده شده در راهنمای انتشار متن پشتیبانی نمی کند.

Quarkus باز است. کلیه وابستگی های این پروژه تحت مجوز نرم افزار Apache 2. 0 یا مجوز سازگار در دسترس است.

این وب سایت با جکیل ساخته شده است ، در صفحات GitHub میزبان است و کاملاً منبع باز است. اگر می خواهید آن را بهتر کنید ، وب سایت را چنگ بزنید و آنچه را که به دست آورده اید به ما نشان دهید.