تراکنش های طولانی مدت یا Long Lived Transactions (LLT)

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

زمان طولانی این تراکنش بدلیل ماهیت عملکردی آن‌ها می باشد:

1. احتمالاً تعداد زیادی از جدوال دیتابیس را مجبور است تا زمان تکمیل تراکنش(موفقیت/شکست آمیز)تحت کنترل داشته باشد.
2. عملی که در حوزه ی این تراکنش های می‌باشد زمان محاسباتی طولانی را نیاز دارد و در این حین منابع دیتابیسی همچنان در وضعیت لاک و بدون استفاده توسط سایر تراکنش های می باشند.
3. ممکن است این تراکنش های پس از انجام یک مرحله در انتظار انتخاب بعدی کاربر جهت ادامه مراحل تراکنش باشند. مثلاً هتل رزرو شده است و جداول مربوطه لاک می‌باشند و در انتظار رزرو پرواز یا پرداخت توسط کاربر هستیم.

در یک سیستم دارای خاصیت Strongly consistency از آنجایی که باید این تراکنش ها بصورت اتومیک(atomic) باشند-یعنی در پایان یا تمام مراحل تراکنش بصورت کامل اجرا شده و در سیستم در وضعیت مورد انتظار پس از تکمیل تراکنش می‌باشد و یا همه چیز به حالت اولیه پیش از اجرای تراکنش باید برگردد- در نتیجه سیستم معمولاً تمامی منابعی که در حین تراکنش درگیر می‌باشند را لاک میکند و از دسترسی سایر تراکنش ها چه جهت خواندن و چه جهت تغییر وضعیت جلوگیری می کند.

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

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

در مثال رزرو هتل-پرواز-پرداخت که یک LLT می باشد می توان آنرا به سه تراکنش رزرو هتلT1- رزرو پروازT2- و پرداخت T3 شکست. و در حالیکه که تراکنش T1 در حال اجرا است منابع مربوط به تراکنش T2و T3 آزاد و قابل استفاده می باشند. پس از اتمام تراکنش T1 تراکنش T2 شروع شده و در این حین منابع T1 نیز از حالت لاک خارج شده و آزاد می باشند.

به LLT که به روش اشاره شده در بالا قابل شکسته شدن به چندین تراکنش کوچکتر باشد SAGA کفته می شود.