معاملات

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

تضمین های ایمنی ارائه شده توسط تراکنش ها اغلب با مخفف ACID خلاصه می شود.

توسعه دهندگان از تضمین های ایمنی ارائه شده توسط پایگاه داده با قرار دادن عملیات در یک تراکنش استفاده می کنند. این تضمین ها اغلب با استفاده از مخفف ACID خلاصه می شوند:

• اتمی: تضمین می کند که تمام یا هیچ یک از عملیات تراکنش ها موفق هستند. تراکنش یا با موفقیت انجام شد یا لغو شد و برگشت خورد.
• Consistent : اطمینان می دهد که وضعیت های پایگاه داده قبل و بعد از تراکنش معتبر هستند (یعنی هرگونه تغییر ناپذیر موجود در مورد داده ها حفظ می شود).
• Isolated: تضمین می کند که تراکنش های همزمان در حال اجرا همان اثری را دارند که اگر به صورت سریال اجرا می شوند.
• دوام: تضمین می کند که پس از موفقیت تراکنش، هر نوشته ای به طور مداوم ذخیره می شود.

در حالی که ابهامات و تفاوت های ظریف زیادی برای هر یک از این ویژگی ها وجود دارد (برای مثال، سازگاری در واقع می تواند به جای یک ویژگی پایگاه داده به عنوان یک مسئولیت در سطح برنامه در نظر گرفته شود یا ایزوله معمولاً از نظر سطوح جداسازی قوی تر و ضعیف تر تضمین می شود)، به طور کلی آنهابه عنوان یک دستورالعمل سطح بالا برای انتظاراتی که توسعه دهندگان در هنگام فکر کردن به تراکنش های پایگاه داده دارند، عمل می کند.

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

Prisma Client از شش روش مختلف برای مدیریت تراکنش ها برای سه سناریو مختلف پشتیبانی می کند:

تکنیکی که انتخاب می کنید به مورد استفاده خاص شما بستگی دارد.

توجه: برای اهداف این راهنما، نوشتن در پایگاه داده شامل ایجاد، به‌روزرسانی و حذف داده‌ها است.

نوشته ها وابسته به یکدیگر در نظر گرفته می شوند اگر:

• عملیات به نتیجه یک عملیات قبلی بستگی دارد (به عنوان مثال، پایگاه داده که یک ID تولید می کند)

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

• ایجاد یک کاربر و دو پست وبلاگ مرتبط (رابطه یک به چند) - شناسه نویسنده باید قبل از ایجاد پست های وبلاگ شناخته شود
• ایجاد یک تیم و اختصاص اعضا (رابطه چند به چند) - شناسه تیم باید قبل از اختصاص اعضا شناخته شود

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

راه حل Prisma برای نوشتن های وابسته، ویژگی نوشتن تودرتو است که توسط ایجاد و به روز رسانی پشتیبانی می شود. نوشتن تو در تو زیر یک کاربر و دو پست وبلاگ ایجاد می کند:

اگر هر عملیاتی با شکست مواجه شود، Prisma کل تراکنش را برمی گرداند. نوشته‌های تودرتو در حال حاضر توسط عملیات انبوه سطح بالا مانند client. user. deleteMany و client. user. updateMany پشتیبانی نمی‌شوند.

زمان استفاده از نوشته های تودرتو

استفاده از نوشتن تو در تو را در نظر بگیرید اگر:

• ✔ می خواهید همزمان دو یا چند رکورد مرتبط با شناسه ایجاد کنید (به عنوان مثال، یک پست وبلاگ و یک کاربر ایجاد کنید)
• ✔ شما می خواهید به طور همزمان سوابق مرتبط با شناسه را به روز کنید و ایجاد کنید (برای مثال ، نام کاربر را تغییر دهید و یک پست وبلاگ جدید ایجاد کنید)

سناریو: جریان ثبت نام

جریان ثبت نام Slack را در نظر بگیرید ، که:

1. یک تیم ایجاد می کند
2. یک کاربر را به آن تیم اضافه می کند ، که به طور خودکار مدیر آن تیم می شود

این سناریو را می توان با طرح زیر نشان داد-توجه داشته باشید که کاربران می توانند متعلق به بسیاری از تیم ها باشند ، و تیم ها می توانند کاربران زیادی داشته باشند (یک رابطه بسیار به بسیاری):

ساده ترین رویکرد ایجاد یک تیم ، ایجاد و پیوستن به کاربر به آن تیم است:

با این حال ، این کد یک مشکل دارد - سناریوی زیر را در نظر بگیرید:

1. ایجاد تیم موفق می شود - "ماجراهای شفق قطبی" اکنون گرفته شده است
2. ایجاد و اتصال کاربر با شکست مواجه می شود - تیم "ماجراهای شفق قطبی" وجود دارد ، اما هیچ کاربر ندارد
3. با عبور از جریان ثبت نام دوباره و تلاش برای بازآفرینی "Aurora Adventures" شکست می خورد - تیم در حال حاضر وجود دارد

ایجاد تیم و اضافه کردن کاربر باید یک عملیات اتمی باشد که به طور کلی موفق یا شکست می خورد.

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

علاوه بر این ، اگر خطایی در هر نقطه ای رخ دهد ، مشتری Prisma کل معامله را پس می گیرد.

سوالات متداول می نویسد

چرا نمی توانم از API معامله $ برای حل همین مشکل استفاده کنم؟

API معاملات $ به شما امکان نمی دهد شناسه را بین عملیات مجزا منتقل کنید. در مثال زیر ، CreateUseroperation. id هنوز در دسترس نیست:

تو در تو می نویسد که به روزرسانی های پشتیبانی از تو در تو در تو در تو می نویسد ، اما به روزرسانی ها وابسته نیستند - آیا باید از API معامله $ استفاده کنم؟

صحیح است که بگوییم زیرا شما شناسه تیم را می شناسید ، می توانید تیم و اعضای تیم آن را به طور مستقل در یک معامله $ به روز کنید. مثال زیر هر دو عمل را در یک معامله $ انجام می دهد:

با این حال ، شما می توانید با نوشتن تو در تو به همان نتیجه برسید:

آیا می توانم چندین نوشتن تو در تو را انجام دهم - به عنوان مثال ، دو تیم جدید ایجاد کرده و به کاربران اختصاص دهم؟

بله ، اما این ترکیبی از سناریوها و تکنیک ها است:

• ایجاد یک تیم و اختصاص کاربران یک نوشتن وابسته است - از نوشتن های تو در تو استفاده کنید
• ایجاد همه تیم ها و کاربران در همان زمان یک نوشتن مستقل است زیرا ترکیب تیم/کاربر شماره 1 و ترکیب تیم/کاربر شماره 2 نامربوط هستند - از API معامله $ استفاده کنید

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

• به روزرسانی قسمت وضعیت لیستی از سفارشات "اعزام"
• نشان دادن لیستی از ایمیل ها به عنوان "خوانده شده"

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

بسته به نیاز شما ، مشتری Prisma چهار گزینه برای رسیدگی به نویسندگان مستقل دارد که باید با هم موفق شوند یا شکست بخورند.

نوشتن فله به شما امکان می دهد چندین سوابق از همان نوع را در یک معامله واحد بنویسید - در صورت عدم موفقیت هرگونه عمل ، Prisma کل معامله را پس می گیرد. PRISMA در حال حاضر پشتیبانی می کند:

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

زمان استفاده از عملیات انبوه

عملیات انبوه را به عنوان یک راه حل در نظر بگیرید اگر:

• ✔ می‌خواهید دسته‌ای از همان نوع رکورد را به‌روزرسانی کنید، مانند دسته‌ای از ایمیل‌ها

سناریو: علامت گذاری ایمیل ها به عنوان خوانده شده

شما در حال ساخت سرویسی مانند gmail. com هستید و مشتری شما یک ویژگی "علامت گذاری به عنوان خوانده شده" را می خواهد که به کاربران امکان می دهد همه ایمیل ها را به عنوان خوانده شده علامت گذاری کنند. هر به‌روزرسانی برای وضعیت یک ایمیل، یک نوشتن مستقل است زیرا ایمیل‌ها به یکدیگر وابسته نیستند - برای مثال، ایمیل "تولدت مبارک! 🍰" از عمه شما با ایمیل تبلیغاتی IKEA ارتباطی ندارد.

در طرح زیر، یک کاربر می تواند ایمیل های دریافتی زیادی داشته باشد (رابطه یک به چند):

بر اساس این طرح، می توانید از updateMany برای علامت گذاری تمام ایمیل های خوانده نشده به عنوان خوانده شده استفاده کنید:

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

خیر - نه updateMany و نه deleteMany در حال حاضر از نوشتن تودرتو پشتیبانی نمی کند. به عنوان مثال، شما نمی توانید چندین تیم و همه اعضای آنها را حذف کنید (حذف آبشاری):

آیا می توانم از عملیات انبوه با $transaction API استفاده کنم؟

بله - برای مثال، می‌توانید چندین عملیات deleteMany را در داخل یک $تراکنش قرار دهید.

$transaction API یک راه حل عمومی برای نوشتن های مستقل است که به شما امکان می دهد چندین عملیات را به صورت یک عملیات اتمی اجرا کنید - اگر هر عملیاتی شکست بخورد، Prisma کل تراکنش را برمی گرداند.

همچنین شایان ذکر است که عملیات بر اساس ترتیبی که در تراکنش قرار می گیرد، اجرا می شود.

توجه: استفاده از پرس و جو در تراکنش بر ترتیب عملیات در خود پرس و جو تأثیری ندارد.

با تکامل Prisma Client، موارد استفاده برای $transaction API به طور فزاینده ای با عملیات انبوه تخصصی تر (مانند createMany ) و نوشتن تو در تو جایگزین می شود.

زمان استفاده از $transaction API

API $transaction را در نظر بگیرید اگر:

• ✔ می‌خواهید دسته‌ای را به‌روزرسانی کنید که شامل انواع مختلفی از رکوردها، مانند ایمیل‌ها و کاربران است. سوابق به هیچ وجه نیازی به ارتباط ندارند.
• ✔ می خواهید پرس و جوهای SQL خام ($executeRaw ) را دسته بندی کنید - به عنوان مثال، برای ویژگی هایی که Prisma Client هنوز از آنها پشتیبانی نمی کند.

سناریو: قانون حفظ حریم خصوصی

GDPR و سایر قوانین حفظ حریم خصوصی به کاربران این حق را می دهد که از یک سازمان درخواست کنند همه داده های شخصی آنها را حذف کند. در طرح مثال زیر، یک کاربر می تواند پست ها و پیام های خصوصی زیادی داشته باشد:

اگر کاربر حق فراموش شدن را استناد کند، باید سه رکورد را حذف کنیم: سابقه کاربر، پیام های خصوصی و پست ها. بسیار مهم است که همه عملیات حذف با هم موفق شوند یا اصلاً موفق نباشند، که این موضوع را به یک مورد استفاده برای تراکنش تبدیل می کند. با این حال، استفاده از یک عملیات انبوه منفرد مانند deleteMany در این سناریو امکان پذیر نیست زیرا ما باید در سه مدل آن را حذف کنیم. در عوض، می‌توانیم از API $transaction برای اجرای سه عملیات با هم استفاده کنیم - دو deleteMany و یکی delete:

سناریو: شناسه های از پیش محاسبه شده و API $transaction

نوشته‌های وابسته توسط $transaction API پشتیبانی نمی‌شوند - اگر عملیات A به شناسه تولید شده توسط عملیات B متکی است، از نوشتن‌های تودرتو استفاده کنید. با این حال، اگر شناسه‌ها را از قبل محاسبه کرده باشید (مثلاً با تولید GUID)، نوشته‌های شما مستقل می‌شوند. جریان ثبت نام را از مثال نوشتن تودرتو در نظر بگیرید:

به جای تولید خودکار شناسه، فیلدهای شناسه تیم و کاربر را به رشته تغییر دهید (اگر مقداری ارائه نکنید، یک UUID به طور خودکار ایجاد می‌شود). این مثال از UUID استفاده می کند:

مثال جریان ثبت نام را اصلاح کنید تا از $transaction API به جای تو در تو استفاده کنید:

از نظر فنی، اگر این نحو را ترجیح می دهید، همچنان می توانید از نوشته های تو در تو با API های از پیش محاسبه شده استفاده کنید:

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

بخوانید ، اصلاح کنید ، بنویسید

در بعضی موارد ممکن است شما نیاز به انجام منطق سفارشی به عنوان بخشی از یک عملیات اتمی داشته باشید-همچنین به عنوان الگوی Read-Mymify-Write شناخته می شود. در زیر نمونه ای از الگوی Read-Mymify-Write است:

• یک مقدار از پایگاه داده بخوانید
• برخی از منطق را برای دستکاری این مقدار اجرا کنید (برای مثال ، تماس با API خارجی)
• مقدار را به پایگاه داده بنویسید

همه عملیات بدون ایجاد تغییرات ناخواسته در پایگاه داده باید موفق یا با هم موفق شوند ، اما لزوماً نیازی به استفاده از یک معامله پایگاه داده واقعی ندارید. در این بخش از راهنما دو روش برای کار با مشتری Prisma و الگوی Read-Mymify-Write شرح داده شده است:

• طراحی API های idempotent
• کنترل همزمانی خوش بینانه

IdemPotency توانایی اجرای همان منطق با همان پارامترها را چندین بار با همان نتیجه است: تأثیر در پایگاه داده همان است که آیا شما یک بار یا یک هزار بار منطق را اجرا می کنید. مثلا:

• نه idempotent: upSert (به روزرسانی یا در این مقاله) کاربر در پایگاه داده با آدرس ایمیل "letoya@prisma. io". جدول کاربر آدرس های ایمیل منحصر به فرد را اجرا نمی کند. تأثیر در پایگاه داده اگر یک بار منطق را اجرا کنید (یک کاربر ایجاد شده) یا ده بار (ده کاربر ایجاد شده) متفاوت است.
• idempotent: UPSERT (به روز رسانی یا این درصدی) کاربر در پایگاه داده با آدرس ایمیل "letoya@prisma. io". جدول کاربر آدرس های ایمیل منحصر به فرد را اجرا می کند. تأثیر در پایگاه داده اگر یک بار منطق را اجرا کنید (یک کاربر ایجاد شده) یا ده بار (کاربر موجود با همان ورودی به روز می شود) یکسان است.

IdemPotency چیزی است که می توانید و باید به طور فعال در برنامه خود در هر کجا که ممکن باشد طراحی کنید.

چه موقع می توان یک API idempotent را طراحی کرد

• ✔ شما باید بدون ایجاد عوارض جانبی ناخواسته در پایگاه داده ها بتوانید همان منطق را امتحان کنید

سناریو: ارتقاء یک تیم Slack

شما در حال ایجاد یک جریان ارتقاء برای Slack هستید که به تیم ها امکان باز کردن ویژگی های پرداخت شده را می دهد. تیم ها می توانند در هر ماه بین برنامه های مختلف و برای هر کاربر پرداخت کنند. شما از Stripe به عنوان دروازه پرداخت خود استفاده می کنید و مدل تیم خود را برای ذخیره StripeCustomerid گسترش می دهید. اشتراک ها در Stripe مدیریت می شوند.

جریان ارتقاء به این شکل است:

1. تعداد کاربران را بشمارید
2. اشتراک در نوار ایجاد کنید که شامل تعداد کاربران باشد
3. تیم را با شناسه مشتری Stripe مرتبط کنید تا ویژگی های پرداخت شده را باز کنید

این مثال یک مشکل دارد: شما فقط می توانید یک بار منطق را اجرا کنید. سناریوی زیر را در نظر بگیرید:

Stripe یک مشتری و اشتراک جدید ایجاد می کند و شناسه مشتری را برمی گرداند

به روزرسانی تیم شکست می خورد - تیم به عنوان مشتری در پایگاه داده SLACK مشخص نمی شود

مشتری توسط Stripe شارژ می شود ، اما ویژگی های پرداخت شده در Slack قفل نمی شوند زیرا تیم فاقد یک مشتری معتبر است

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

• منجر به خطا می شود زیرا تیم (تعریف شده توسط ExternalID) در حال حاضر وجود دارد - Stripe هرگز شناسه مشتری را بر نمی گرداند
• اگر ExternalID مشمول محدودیت منحصر به فرد نیست ، Stripe اشتراک دیگری را ایجاد می کند (نه idempotent)

در صورت بروز خطا نمی توانید این کد را دوباره اجرا کنید و بدون اینکه دو بار شارژ شود ، نمی توانید به یک برنامه دیگر تغییر دهید.

اصلاح کننده زیر (برجسته) مکانیسمی را معرفی می کند که آیا اشتراک از قبل وجود دارد ، یا توضیحات را ایجاد می کند یا اشتراک موجود را به روز می کند (که اگر ورودی یکسان باشد بدون تغییر باقی می ماند):

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

کنترل همزمانی خوش بینانه

کنترل همزمان خوشبینانه (OCC) مدلی برای مدیریت عملیات همزمان روی یک موجودیت واحد است که به قفل 🔒 متکی نیست. در عوض، ما خوش بینانه فرض می کنیم که یک رکورد در بین خواندن و نوشتن بدون تغییر باقی می ماند و از یک نشانه همزمانی (مهر زمانی یا فیلد نسخه) برای تشخیص تغییرات یک رکورد استفاده می کنیم.

اگر تداخل ❌ رخ دهد (فردی دیگر از زمانی که شما رکورد را خوانده اید تغییر داده است)، تراکنش را لغو می کنید. بسته به سناریوی خود، می توانید:

• معامله را دوباره امتحان کنید (یک صندلی سینما رزرو کنید)
• پرتاب یک خطا (به کاربر هشدار می دهد که می خواهد تغییرات ایجاد شده توسط شخص دیگری را بازنویسی کند)

این بخش نحوه ایجاد کنترل همزمان خوشبینانه خود را شرح می دهد. همچنین ببینید: برنامه هایی برای کنترل همزمانی خوش بینانه در سطح برنامه در GitHub

اگر از نسخه 4. 4. 0 یا نسخه قبلی استفاده می کنید، نمی توانید از کنترل همزمان خوش بینانه در عملیات به روز رسانی استفاده کنید، زیرا نمی توانید فیلدهای غیر منحصر به فرد را فیلتر کنید. فیلد نسخه ای که باید با کنترل همزمانی خوش بینانه استفاده کنید، یک فیلد غیر منحصر به فرد است.

از نسخه 4. 5. 0، می توانید فیلدهای غیر منحصر به فرد را در عملیات به روز رسانی فیلتر کنید، بنابراین می توانید از کنترل همزمان خوش بینانه با عملیات به روز رسانی استفاده کنید. برای انجام این کار، از ویژگی پیش نمایش ExtendedWhereUnique استفاده کنید.

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

• ✔ شما تعداد زیادی درخواست همزمان را پیش بینی می کنید (چند نفر صندلی سینما را رزرو می کنند)
• ✔ پیش‌بینی می‌کنید که تضاد بین آن درخواست‌های همزمان نادر باشد

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

سناریو: رزرو صندلی در سینما

شما در حال ایجاد یک سیستم رزرو برای یک سینما هستید. هر فیلم دارای تعدادی صندلی است. طرحواره زیر فیلم ها و صندلی ها را مدل می کند:

کد نمونه زیر اولین صندلی موجود را پیدا می کند و آن صندلی را به کاربر اختصاص می دهد:

با این حال، این کد از "مشکل رزرو دوگانه" رنج می برد - این امکان وجود دارد که دو نفر یک صندلی را رزرو کنند:

1. Seat 3A به Sorcha بازگشت ( findFirst )
2. صندلی 3A به الن بازگشت (findFirst)
3. صندلی 3A توسط Sorcha (به روز رسانی)
4. صندلی 3A ادعا شده توسط الن (به روز رسانی - ادعای Sorcha را بازنویسی می کند)

حتی اگر Sorcha با موفقیت این صندلی را رزرو کرد، این سیستم در نهایت ادعای الن را ذخیره می کند. برای حل این مشکل با کنترل همزمان خوشبینانه، یک فیلد نسخه را به صندلی اضافه کنید:

سپس، کد را تنظیم کنید تا قبل از به‌روزرسانی، قسمت نسخه را بررسی کنید:

اکنون امکان رزرو یک صندلی برای دو نفر وجود ندارد:

1. Seat 3A به Sorcha بازگشت (نسخه 0 است)
2. Seat 3A به الن بازگشت (نسخه 0 است)
3. صندلی 3A ادعا شده توسط Sorcha (نسخه به 1 افزایش یافت، رزرو با موفقیت انجام شد)
4. صندلی 3A ادعا شده توسط الن (نسخه درون حافظه (0) با نسخه پایگاه داده (1) مطابقت ندارد - رزرو انجام نشد)

اگر یک برنامه کاربردی موجود دارید، می‌تواند برای استفاده از کنترل همزمان خوش‌بینانه برنامه‌تان را تغییر دهید. Interactive Transactions یک دریچه فرار مفید برای مواردی مانند این ارائه می دهد.

برای ایجاد یک معامله تعاملی ، یک تابع ASYNC را به معامله $ منتقل کنید.

اولین استدلال که در این عملکرد ASYNC گذشت ، نمونه ای از مشتری Prisma است. در زیر ، ما این نمونه TX را صدا خواهیم کرد. هر تماس Prisma که در این نمونه TX فراخوانی شده است ، در معامله محصور می شود.

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

نتیجه مورد انتظار برای آلیس خواهد بود که 1 انتقال را برای 100 دلار انجام دهد و انتقال دیگر رد شود. این امر باعث می شود آلیس 0 دلار و باب 200 دلار داشته باشد.

در مثال بالا ، هر دو نمایش داده به روزرسانی در یک معامله پایگاه داده اجرا می شوند. هنگامی که برنامه به پایان عملکرد می رسد ، معامله به پایگاه داده متعهد می شود.

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

می توانید در مورد معاملات تعاملی در معاملات و اسناد و مدارک دسته ای ما اطلاعات بیشتری کسب کنید.

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

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