با استفاده از معاملات در Quarkus

Quarkus با یک مدیر معامله همراه است و از آن برای هماهنگی و افشای معاملات در برنامه های شما استفاده می کند. هر برنامه افزودنی با پایداری با آن برای شما ادغام می شود. و شما صریحاً با معاملات از طریق CDI تعامل خواهید داشت. این راهنما شما را در تمام این موارد طی می کند.

تنظیم آن

نیازی نیست که بیشتر اوقات آن را نگران کنید زیرا پسوندهایی که به آن نیاز دارند ، به سادگی آن را به عنوان یک وابستگی اضافه می کنند. به عنوان مثال Hibeate ORM شامل مدیر تراکنش خواهد بود و آن را به درستی تنظیم می کند.

اگر به عنوان مثال از معاملات مستقیم بدون ORM Hibeate استفاده می کنید ، ممکن است لازم باشد آن را به عنوان یک وابستگی اضافه کنید. موارد زیر را به پرونده ساخت خود اضافه کنید:

شروع و متوقف کردن معاملات: تعریف مرزهای خود

شما می توانید مرزهای معامله خود را یا به صورت اعلامیه با transactional یا برنامه ای با Quarkustransaction تعریف کنید. همچنین می توانید مستقیماً از JTA UserTransaction API استفاده کنید ، اما این کمتر از Quarkustransaction کاربر پسند است.

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

ساده ترین راه برای تعریف مرزهای معامله شما استفاده از حاشیه نویسی transactional در روش ورود شما است (javax. transaction. transactional).

transactional می تواند برای کنترل مرزهای معامله در هر لوبیای CDI در سطح روش یا در سطح کلاس استفاده شود تا اطمینان حاصل شود که هر روش معامله است. این شامل نقاط پایانی است.

شما می توانید کنترل کنید که آیا و چگونه معامله با پارامترهای موجود در transactional شروع می شود:

transactional (مورد نیاز) (پیش فرض): اگر هیچکدام شروع نشود ، معامله را شروع می کند ، در غیر این صورت با یکی موجود باقی می ماند.

transactional (needes_new): اگر هیچکدام شروع نشد ، معامله را شروع می کند. اگر یک مورد موجود آغاز شد ، آن را به حالت تعلیق در می آورد و یک روش جدید را برای مرز آن روش شروع می کند.

transactional (اجباری): در صورت عدم انجام معامله ، شکست می خورد. در غیر این صورت در معامله موجود کار می کند.

transactional (پشتیبانی): اگر معامله ای آغاز شد ، به آن می پیوندد. در غیر این صورت بدون معامله کار می کند.

transactional (not_supported): اگر معامله شروع شد ، آن را به حالت تعلیق در می آورد و بدون معامله برای مرز روش کار نمی کند. در غیر این صورت بدون معامله کار می کند.

transactional (هرگز): اگر معامله آغاز شد ، یک استثنا را ایجاد می کند. در غیر این صورت بدون معامله کار می کند.

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

متن معامله به کلیه تماس های توخالی در روش transactional همانطور که انتظار دارید پخش می شود (در این مثال ChildDao. AddtogiftList () و santadao. addtosantatodolist ()). معامله مرتکب خواهد شد مگر اینکه یک استثناء زمان اجرا از مرز روش عبور کند. شما می توانید با استفاده از transactional (dontrollbackon = someexception. class) (یا Rollbackon) ، استثناء را مجبور کنید یا خیر.

همچنین می توانید به صورت برنامه ای بخواهید معامله ای را برای بازگشت به صورت مشخص کنید. برای این کار یک TraderManager تزریق کنید.

پیکربندی معامله

پیکربندی پیشرفته معامله با استفاده از حاشیه نویسی transactionConfiguration که علاوه بر حاشیه نویسی استاندارد transactional در روش ورود شما یا در سطح کلاس تنظیم شده است ، امکان پذیر است.

حاشیه نویسی TransactionConfiguration اجازه می دهد تا در چند ثانیه یک ویژگی زمان بندی را تنظیم کنید که در مورد معاملات ایجاد شده در روش حاشیه نویسی اعمال می شود.

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

اگر در یک کلاس تعریف شود ، معادل تعریف آن در تمام روشهای کلاس مشخص شده با transactional است. پیکربندی تعریف شده بر روی یک روش بر پیکربندی تعریف شده در یک کلاس تقدم می کند.

پسوندهای واکنشی

اگر روش transactiona l-aotated شما یک مقدار واکنشی مانند:

مرحله تکمیل (از JDK)

ناشر (از جریان واکنشی)

هر نوع که می تواند با استفاده از مبدل های نوع واکنش پذیر به یکی از دو نوع قبلی تبدیل شود

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

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

اگر نیاز به انتشار زمینه معامله خود در خط لوله واکنشی خود دارید ، لطفاً به راهنمای انتشار متن مراجعه کنید.

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

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

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

مثال دوم استفاده از معاملات scoped lambda را نشان می دهد ، اولین بار فقط در یک معامله قابل اجرا است ، دوم ، با برخی از گزینه های خاص قابل تماس است. به طور خاص از روش استثنائیدر می توان برای کنترل استفاده کرد اگر معامله به استثناء برگردانده شود یا نه ، و روش معنایی در صورت شروع معامله موجود ، رفتار را کنترل می کند.

معانی زیر پشتیبانی می شود:

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

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

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

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

رویکرد API میراث

روش کمتر آسان برای تزریق کاربری و استفاده از روشهای مختلف تعیین معاملات است.

شما نمی توانید از usertransaction در روشی که معامله با یک تماس transactional شروع شده است استفاده کنید.

پیکربندی زمان معامله

شما می توانید زمان پیش فرض معامله را پیکربندی کنید ، مدت زمان بندی که در مورد کلیه معاملات مدیریت شده توسط مدیر معامله ، از طریق ملک quarkus. transaction-manager. default-trancaction-timeout ، که به عنوان یک مدت مشخص شده است ، پیکربندی کنید.

قالب برای مدت زمان استفاده از فرمت استاندارد java. time. duration. می توانید در مورد آن در مدت زمان#پارس () Javadoc اطلاعات بیشتری کسب کنید.

همچنین می توانید مقادیر مدت زمان را با یک عدد شروع کنید. در این حالت ، اگر مقدار فقط از یک عدد تشکیل شود ، مبدل مقدار را به عنوان ثانیه رفتار می کند. در غیر این صورت ، PT به طور ضمنی برای به دست آوردن یک فرمت java. time. duration استاندارد به ارزش آماده می شود.

مقدار پیش فرض 60 ثانیه است.

پیکربندی شناسه نام گره معامله

Narayana ، به عنوان مدیر معامله اساسی ، مفهومی از شناسه گره منحصر به فرد دارد. این مهم است اگر در نظر بگیرید از معاملات XA که شامل چندین منبع است استفاده کنید.

شناسه نام گره نقش مهمی در شناسایی یک معامله دارد. شناسه نام گره هنگام ایجاد معامله در شناسه معامله جعل می شود. بر اساس شناسه نام گره ، مدیر معامله قادر به شناخت همتایان تراکنش XA ایجاد شده در پایگاه داده یا کارگزار JMS است. شناسه این امکان را برای مدیر معامله فراهم می کند تا در هنگام بهبودی ، همتایان معامله را پس بگیرد.

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

شناسه نام گره ممکن است از طریق ویژگی quarkus. transaction-manager. node-name پیکربندی شود.

با استفاده از transactionscoped برای اتصال لوبیای CDI به چرخه عمر معامله

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

فقط با استفاده از حاشیه نویسی transactionscoped ، دامنه معامله را به چنین لوبیا اختصاص دهید:

از طرف دیگر ، اگر لزوماً نیازی به نگه داشتن حالت در طول معامله ندارید و فقط می خواهید در برابر رویدادهای شروع/پایان معامله واکنش نشان دهید ، می توانید شنوندگان رویداد را در یک لوبیای متفاوتی اعلام کنید:

چرا همیشه مدیر معامله دارید؟

بله ، در برنامه Quarkus شما ، در IDE ، در آزمایشات شما کار می کند ، زیرا همه اینها برنامه های Quarkus هستند. JTA برای برخی از افراد مطبوعات بدی دارد. من نمی دانم چرابیایید فقط بگوییم که این اجرای JTA پدربزرگ شما نیست. آنچه ما داریم کاملاً قابل تعبیه و لاغر است.

آیا این برنامه 2 فاز انجام می دهد و برنامه من را کند می کند؟

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

من وقتی فقط عملیات را می خوانم ، نیازی به معامله ندارم ، سریعتر است.

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

چرا API مدیریت معامله Hibeate JTA vs Hibeate را ترجیح می دهید

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

این یک آشفتگی است زیرا من نمی دانم واحد پایداری JPA من از JTA یا معامله در سطح منابع استفاده می کند

این یک آشفتگی در Quarkus نیست :) سطح منابع برای پشتیبانی از JPA در یک محیط غیر مدیریت شده معرفی شد. اما Quarkus هم لاغر است و هم یک محیط مدیریت شده ، بنابراین ما با اطمینان می توانیم همیشه فرض کنیم که در حالت JTA هستیم. نتیجه نهایی این است که مشکلات اجرای Hibeate ORM + CDI + مدیر معامله در حالت Java SE توسط Quarkus حل می شود.

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

این وب سایت با جکیل ساخته شده است ، در صفحات GitHub میزبان است و کاملاً منبع باز است. اگر می خواهید آن را بهتر کنید ، وب سایت را چنگ بزنید و آنچه را که به دست آورده اید به ما نشان دهید.< Pan> مدیریت معاملات به صورت دستی از طریق EntityManager. getTransaction (). شروع () و دوستان منجر به یک کد زشت باسن با تن تلاش می شوند و سرانجام مردم اشتباه می کنند. معاملات همچنین در مورد JMS و دسترسی به پایگاه داده دیگر است ، بنابراین یک API بیشتر حس می کند.