وحید نصیری وحید نصیری
مشکل همزمانی خواندن و به روز رسانی اطلاعات در برنامه‌های وب
اندازه‌ی قلم متن
تخمین مدت زمان مطالعه‌ی مطلب: شش دقیقه
فرض کنید در برنامه‌ی خود «کیف پولی» را طراحی کرده‌اید که بر اساس آن، کاربر می‌تواند خرید کند. این کیف پول، از Id کاربر و موجودی فعلی او تشکیل می‌شود:
CREATE TABLE accounts (
user_id INTEGER PRIMARY KEY,
balance INTEGER NOT NULL
);
و برای مثال موجودی فعلی کاربر 1، مقدار 300 است:
INSERT INTO accounts(user_id, balance)
VALUES (1, 300);
اکنون کوئری‌های متداول زیر را که از یک read و سپس update تشکیل شده‌اند، درنظر بگیرید:
DECLARE @amount INT;

SET @amount = (
SELECT balance
FROM accounts
WHERE user_id = 1
);

SELECT @amount as 'balance'

UPDATE accounts
SET balance =  @amount - 100
WHERE user_id = 1;

SELECT balance as 'balance after shopping'
FROM accounts
WHERE user_id = 1
- دو عمل read و سپس update صورت گرفته‌ی فوق، مربوط به یک درخواست خرید است.
- در اینجا مقدار متغیر amount در ابتدای کار، مساوی 300 است که مربوط به همان insert ابتدایی است.
- سپس از این مقدار در کوئری دومی (برای مثال حاصل از خرید شماره یک)، 100 واحد کم می‌شود (برای مثال قیمت کل خرید است).
- در این حالت نتیجه‌ی آن یا همان موجودی جدید کاربر، 200 خواهد بود.

معادل این عملیات در EF-Core چنین دستورات متداولی است:
var account1 =  context.Accounts.First(x => x.UserId == 1);
account1.Balance -= 100;
context.SaveChanges();

سؤال: اگر کوئری‌های فوق را در یک برنامه‌ی ذاتا چند ریسمانی وب، دوبار به صورت همزمان اجرا کنیم، یعنی دو عمل خرید موازی را شبیه سازی کنیم، چه اتفاقی رخ می‌دهد؟ آیا موجودی نهایی اینبار برای مثال 100 می‌شود (با فرض 300 بودن موجودی ابتدایی)؟
پاسخ خیر است! و آن‌را می‌توانید در تصویر زیر مشاهده کنید:



در اینجا برای شبیه سازی اجرای موازی دو کوئری، از دستور WAITFOR TIME استفاده شده‌است که برای برای آزمایش آن می‌توانید مقدار آن‌را به یک دقیقه بعد تنظیم کرده و سپس آن‌را در دو پنجره‌ی SQL server management studio اجرا کنید.
همانطور که مشاهده می‌کنید، با اجرای موازی این دو کوئری، یعنی دوبار خرید کردن همزمان، 100 واحد گم شده‌است ! به این مشکل همزمانی read و سپس update رخ داده، یک «race condition» گفته می‌شود و این روزها که مطالب منتشر شده‌ی از آسیب پذیری‌های برنامه‌های وب ایرانی را بررسی می‌کنم، این مورد در صدر آن‌ها قرار دارد!
علت اینجا است که عموما برنامه نویس‌ها، برنامه‌های وب را در یک تک سشن باز شده‌ی توسط مرورگر خود آزمایش می‌کنند و در این حالت، همه چیز خوب است و اعمال آن به ترتیب پیش می‌روند. اما فراموش می‌کنند که می‌توان قسمت‌های مختلف برنامه‌های وب را به صورت همزمان، موازی و چندباره نیز اجرا کرد؛ حتی اگر آن قسمت متعلق به یک کاربر باشد.


سؤال: آیا استفاده تراکنش‌ها این مشکل را حل نمی‌کنند؟!

عموما برنامه نویس‌ها تصور می‌کنند که می‌توانند تمام اینگونه مشکلات را با تراکنش‌ها حل کنند:



همانطور که مشاهده می‌کنید، اینبار هرچند هر دو عملیات خرید داخل BEGIN TRAN و COMMIT TRAN قرار گرفته‌اند، اما ... مشکل همزمانی هنوز پابرجا است! چون نوع پیش‌فرض تراکنش مورد استفاده، READ COMMITTED isolation level است و عدم دقت به آن ممکن است این تصور را ایجاد کند که با تعریف تراکنش‌ها، تمام مشکلات همزمانی برطرف می‌شوند.


راه‌حل‌های پیشنهادی جهت حل مشکل همزمانی عملیات read/update

برای حل مشکلات مرتبط با race condition و همزمانی درخواست‌های read/update، می‌توان از یکی از روش‌های زیر استفاده کرد:
الف) بجای اینکه یکبار کوئری read و یکبار کوئری update به صورت جداگانه صادر شوند، فقط یکبار کوئری update داشته باشیم.
ب) پیاده سازی Row level locking؛ در صورت پشتیبانی بانک اطلاعاتی مورد استفاده از آن
ج) استفاده از تراکنش‌هایی از نوع SERIALIZABLE
د) پیاده سازی optimistic locking

این موارد را در ادامه با توضیحات بیشتری بررسی می‌کنیم.


الف) پرهیز از خواندن و به روز رسانی جداگانه

بجای اینکه مانند اعمال فوق، یکبار select داشته باشیم و یکبار  update، بهتر است فقط یک دستور update بکارگرفته شود:
UPDATE accounts
SET balance =  balance - 100
WHERE user_id = 1;


اینبار با خلاصه شدن دو دستور select و update به یک دستور update، دیگر پس از دو خرید همزمان، 100 واحد گم شده مشاهده نمی‌شود (!) و موجودی نهایی صحیح است.


ب) پیاده سازی Row level locking

همیشه امکان تغییر عملیات مورد نیاز، به سادگی حالت الف نیست. در یک چنین حالت‌هایی جهت حداقل شدن تغییرات مورد نیاز، می‌توان از row level locking استفاده کرد:
WAITFOR TIME '13:47:00';

SET NOCOUNT, XACT_ABORT ON;

BEGIN TRAN;

DECLARE @amount INT;

SET @amount = (
 SELECT balance
 FROM accounts WITH (UPDLOCK, HOLDLOCK)
 WHERE user_id = 1
 );

SELECT @amount as 'initial user''s balance'

UPDATE accounts
SET balance =  @amount - 100
WHERE user_id = 1;

SELECT balance as 'user''s balance after shopping 1'
FROM accounts
WHERE user_id = 1;

COMMIT TRAN;



در اینجا اضافه شدن WITH (UPDLOCK, HOLDLOCK) را به Select تعریف شده، مشاهده می‌کنید که به آن‌ها locking hints هم گفته می‌شود و داخل BEGIN TRAN و COMMIT TRAN عمل می‌کنند (که نوع پیش‌فرض آن READ COMMITTED isolation level است). کار UPDLOCK، تبدیل shared lock پیش‌فرض، به update lock است و کار HOLDLOCK، نگه داشتن قفل صورت گرفته تا پایان کار تراکنش تعریف شده‌است.
با این تغییرات، هر تراکنش همزمان دیگری، تا زمانیکه قفل صورت گرفته‌ی بر روی ردیف select، رها نشود (یعنی تا زمانیکه تراکنش قفل کننده، به COMMIT TRAN برسد)، نمی‌تواند آن‌را تغییر دهد. به همین جهت است که در تصویر فوق، هرچند هر دو عملیات همزمان اجرا شده‌اند، اما یکی موجودی ابتدایی 300 را می‌بیند و دیگری پس از صبر کردن تا پایان تراکنش و رها شدن قفل، موجودی تغییر یافته‌ی جدیدی را مشاهده کرده و از آن استفاده می‌کند. به این ترتیب دیگر 100 واحدی که در اولین تصویر این مطلب مشاهده کردید، گم نشده‌است.


ج) استفاده از تراکنش‌هایی از نوع SERIALIZABLE

بجای استفاده از روش row level locking یاد شده، روش دیگری را که می‌توان استفاده کرد، تغییر نوع پیش‌فرض تراکنش مورد استفاده‌است. برای مثال اگر از یک SERIALIZABLE transaction استفاده کنیم؛ یعنی SET TRANSACTION ISOLATION LEVEL SERIALIZABLE  را در ابتدای کار ذکر کنیم و برای مثال دو تراکنش همزمان را اجرا کنیم، اگر در تراکنش اول اطلاعاتی خوانده شود، در هیچ تراکنش دیگری نمی‌توان این اطلاعات خوانده شده را تا پایان کار تراکنش اول، تغییر داد:




د) پیاده سازی optimistic locking

پیاده سازی optimistic locking و یا Optimistic concurrency control عموما در سمت برنامه رخ می‌دهد و توسط ORMها زیاد مورد استفاده قرار می‌گیرد؛ مانند اضافه کردن ستون اضافی version و یا timestamp به جداول تعریف شده. در این حالت تمام updateها به همراه یک where اضافی هستند تا بررسی کنند که آیا version دریافتی در حین خواندن ردیف در حال به روز رسانی، تغییر کرده‌است یا خیر؟ اگر تغییر کرده‌است، تراکنش را با خطایی خاتمه خواهند داد. این روش برخلاف حالت‌های ب و ج، حتی خارج از یک تراکنش نیز کار می‌کند و مشکلات قفل کردن طولانی مدت رکوردها توسط آن‌ها را به همراه ندارد.
‫۲ سال قبل، دوشنبه ۳۱ مرداد ۱۴۰۱، ساعت ۱۹:۴۵
۶۸۲۰
۱۳
Entity frameworkSQL ServerSecurityT-SQLEntity framework Core
مطالب مشابه
  • #
    وحید نصیری وحید نصیری
    ‫۲ سال قبل، دوشنبه ۳۱ مرداد ۱۴۰۱، ساعت ۲۳:۱۸
    منابعی برای مطالعه‌ی بیشتر
  • #
    علیرضا آرانی علیرضا آرانی
    ‫۲ سال قبل، چهارشنبه ۲ شهریور ۱۴۰۱، ساعت ۱۶:۰۱
    شبیه سازی Row level locking در Entity Framework 


    using (var scope = new TransactionScope(...))
{
    using (var context = new YourContext(...))
    {
        var wallet = 
            context.ExecuteStoreQuery<UserWallet>("SELECT UserId, WalletId, Balance FROM UserWallets WITH (UPDLOCK) WHERE ...");

        // your logic

        scope.Complete();
    }
}

    • #
      وحید نصیری وحید نصیری
      ‫۲ سال قبل، چهارشنبه ۲ شهریور ۱۴۰۱، ساعت ۱۶:۲۴
      - در این مثال در حالت پیش‌فرض READ COMMITTED isolation level تراکنش، هرچند وجود UPDLOCK ضروری است، اما کافی نیست و باید به همراه HOLDLOCK هم باشد، تا اثر آن تا پایان تراکنش باقی بماند تا هم select و هم update، در حالت‌های پردازش موازی، هر دو تحت کنترل قرار گیرند.
      - روش اضافه کردن خودکار این hintها به تمام کوئری‌های EF، با استفاده از Interceptorها، بدون نیاز به SQL نویسی مستقیم و عدم استفاده از LINQ: « بهبود عملکرد SQL Server Locks در سیستم‌های با تعداد تراکنش بالا در Entity Framework »
  • #
    میثم نوایی میثم نوایی
    ‫۲ سال قبل، شنبه ۵ شهریور ۱۴۰۱، ساعت ۱۴:۲۲
    به جز وب، این مشکل در چت بات‌ها هم مرسوم است. یادمه یک بات برای پروموشن و دریافت تخفیف یک شرکت ایرانی نوشته بودیم. اما چون race condition رو توش درست هندل نکرده بودیم، بعضی از تینیجرها یک روشی رو یاد گرفته بودند که اینترنت گوشی شون رو قطع میکردند، ده‌ها بار روی دکمه دریافت تخفیف (inline button) کلیک میکردند، بعد اینترنت رو که وصل میکردند، تلگرام همه درخواست‌ها رو یکجا (در کسری از ثانیه) میفرستاد به webhook ما و ممکن بود چندتا کد تخفیف، برای کاربر ارسال بشه.
  • #
    مرتضی میرشکار مرتضی میرشکار
    ‫۲ سال قبل، جمعه ۲۵ شهریور ۱۴۰۱، ساعت ۲۳:۰۵
    سلام آیا استفاده از روش optimistic locking میتونه مشکلات هم زمانی برای خرید محصولات رو برطرف کنه؟ یا کار‌های بیشتری نیازه
  • #
    محمد جواد ابراهیمی محمد جواد ابراهیمی
    ‫۱ سال و ۲ ماه قبل، شنبه ۲۰ خرداد ۱۴۰۲، ساعت ۱۵:۲۱
    ممنون بابت مطلب خوب تون، در ادامه صحبت‌های شما خواستم چند مورد رو اضافه کنم

    1- مشکل مطرح شده اصطلاحا Lost Update نام داره (که در مثال جاری باعث میشه یکی از بروزرسانی‌های عمل خرید گم بشه!)
    این مشکل توسط Isolation Level سطوح Repeatable Read و Serializable قابل حل هست. 
    جدول زیر لیست مشکلات همزمانی به ازای هر سطح از Isolation Level رو نشون میده.


    2- استفاده از سطح Isolation Level بالاتر به معنی سخت گیری و احتیاط بیشتر هست و باعث افزایش میزان Blocking و متعاقبا احتمال وقوع Deadlock و نیز کاهش Performance و ظرفیت Concurrency (همزمانی) دیتابیس میشه (و بلعکس)
    پس اگر مشکلی رو تونستین با Isolation Level سطح پایین‌تری مثل Repeatable Read حل کنید بهتره نسبت به اینکه Isolation Level سطح بالا‌تری مثل Serializable رو انتخاب کنین
     در تصویر زیر نحوه حل اش با Isolation Level سطح Repeatable Read رو مشاهده میکنین


    3- برخلاف روش‌های دیگه، استفاده از Isolation Level سطح Repeatable Read و نیز Serializable در مثال جاری میتونه باعث وقوع Deadlock (بن بست) بشه و این بستگی به این داره که 2 تراکنش در چه نقطه ای به همزمانی میخورن
    همونطور که در 2 تصویر زیر میبینین WAITFOR DELAY اولی باعث قوقع Deadlock میشه ولی دومی نمیشه
    مثال وقوع Deadlock

    توضیح:
    اجازه بدید قبل از توضیح چرایی وقوع Deadlock مروری بر چیستی اون داشته باشیم
    این مشکل زمانی پیش میاد که 2تا تراکنش مانع اجرای هم دیگه میشن و در بن بستی گیر میکنن که هیچ کدوم نمیتونن کارشون رو تموم کن. به عنوان مثال تراکنش اول قفل A رو به دست میگیره و منتظر آزاد شدن قفل B میشه در حالی که تراکنش دوم قفل B رو به دست گرفته و منتظر آزاد شدن قفل A میشه، در این حالت هر دو تراکنش منتظر اتمام کار یکدیگر هستند و در بن بستی گیر میکنن (Deadlock) که هیچ کدوم نمتونن کارشون رو تموم کنن
    در این شرایط SQL Server به ناچار یکی از اون‌ها (در واقع تراکنشی که Rollback اش هزینه کمتری داره) رو به عنوان Victim (قربانی) حساب میکنه و اون رو  Rollback و سپس Kill میکنه تا حداقل دیگری بتونه به کارش ادامه بده

    در Isolation Level سطح Serializable و Repeatable Read هر رکوردی که خونده (SELECT) بشه، از تغییر (UPDATE و DELETE) شدن همون رکورد توسط دیگر تراکنش‌ها جلوگیری میشه مادامی که تراکنش اول کارش تموم بشه
    پس ترکنش اول مقدار balance رو SELECT میکنه، در همین حال تراکنش دوم نیز مقدار balance رو SELECT میکنه
    سپس تراکنش اول میخواد مقدار balance رو UPDATE کنه ولی Block (مسدود) میشه چرا کنه همین رکورد قبلا توسط تراکنش دوم قفل شده، پس منتظر (Wait) تراکنش دوم میشه 
    تراکنش دوم نیز میخواد مقدار balance رو UPDATE کنه و این هم Block (مسدود) میشه چرا کنه همین رکورد قبلا توسط تراکنش اول قفل شده، پس منتظر (Wait) تراکنش اول میشه و BOOM !! بن بست یا Deadlock رخ میده، چرا که هر دو تراکنش Block یکدیگه شدن و منتظر آزاد شدن قفل توسط دیگری هستند 

    مثال عدم وقوع Deadlock

    توضیح:
    در این حالت اما تراکنش اول عمل SELECT و UPDATE رو زودتر از تراکنش دوم انجام میده و عمل UPDATE اش توسط تراکنش دوم بلاک (Block) نمیشه چرا که تراکنش دوم هنوز شروع نشده
    دقت داشته باشین که در این مثال از WAITFOR TIME استفاده نکردیم که بخواد دقیقا در یک زمان مشخص، هر دو تراکنش رو اجرا بکنه بلکه چون دستی داریم کوئری‌ها رو اجرا میکنیم، همین تاخیر یک ثانیه ایی باعث میشه تراکنش اول کارش رو زودتر شروع کنه و فقط در میانه راه و بعد از عمل UPDATE به همزمانی بخورن

    4- هینت HOLDLOCK معادل Isolation Level سطح Serializable هست، برای استفاده از سطح Repeatable Read میتونیم از هینت REPEATABLEREAD استفاده کنیم
    صرفا جهت مرور:
    عبارات Table Hints دستور هایی هستند که رفتار پیشفرض Query Optimizer (بهینه ساز کوئری) رو به هنگام دستورات DML (مثل SELECT/INSERT/UPDATE/DELETE) تغییر میده (override میکنن) و معمولا برای تغییر سطح قفل و Isolation Level و یا انتخاب Index دلخواه استفاده میشه


    5- هینت UPDLOCK دو تا کار انجام میده
    1- باعث میشه به جای قفل Shared Lock یا (S) از قفل Update Lock یا (U) بر روی رکورد‌های خوانده شده استفاده بشه
    2- همانند سطح Repeatable Read و Serializable (هینت HOLDLOCK) قفل رو تا اتمام Trasanction (و نه صرفا Statement) نگه میداره (Hold میکنه) 
    پس در این مثال خاص (و نه همه جا، که دلیل اون رو جلوتر بررسی میکنیم) میتونیم بدون HOLDLOCK هم انجامش بدیم و نیازی به اون نخواهیم داشت.
    هینت UPDLOCK معمولا زمانی استفاده میشه که میخوایم رکورد یا رکورد هایی رو  در Statement‌های بعدی تراکنش جاری UPDATE کنیم و نمی‌خوایم در این بین تراکنش همزمان دیگری این دیتا رو تغییر بده


    6- دقت داشته باشین که این تصور که چون UPDLOCK و HOLDLOCK هر دو در نگه داشتن (Hold کردن) قفل تا انتهای تراکنش (و نه Statement جاری) مشترک هستند پس به هنگام استفاده از UPDLOCK دیگر نیازی به HOLDLOCK نداریم تصور اشتباهی هست و علت ظریفی داره
    یا بهتره این سوال رو اینطور مطرح کنیم که: 
    پس چرا استفاده از  HOLDLOCK در کنار UPDLOCK رایج هست؟ و چه فرقی میکنه که HOLDLOCK در کنار UPDLOCK استفاده بکنیم یا خیر؟

    قبل از بررسی چرایی این موضوع بهتره مروری بر روی Repeatable Read و Serializable از منظر Lock Mode‌ها (حالات قفل) داشته باشیم

    سطح Repeatable Read
    در این سطح قفل Shared صرفا به ازای رکورد‌های SELECT شده ایجاد میشه ولی برخلاف Read Committed قفل رو تا اتمام Transaction نگه میداره داره (Hold میکنه) - (نه به محض اتمام Statement)
    در نتیجه تا پایان تراکنش جاری  از هر گونه تغییر بر روی دیتای Read شده توسط دیگر تراکنش‌های همزمان جلوگیری میکنه

    سطح Serializable
    این سطح مشابه سطح Repeatable Read عمل میکنه (یعنی قفل رو تا اتمام تراکنش و نه صرفا Statement جاری نگه میداره) با این تفاوت که از قفل Key-Range Lock به جای Shared Lock استفاده میکنه (البته نه همیشه و استثنا هایی هم وجود داره که جلوتر بررسی میکنیم) و کل بازه (محدوده) رکورد‌های SELECT شده بر اساس شرط WHERE رو قفل گذاری میکنه (بر خلاف Repeatable Read که صرفا به ازای رکورد‌های SELECT شده قفل ایجاد میکرد)
    و بدین صورت از مشکل Phantom Read (مانند INSERT شدن رکورد جدیدی در بازه/محدوده قفل شده) جلوگیری میشه
    به عنوان مثال در Serializable شرط WHERE Age BETWEEN 18 AND 35 یک قفل Key-Range Lock بر روی بازه (محدوده) 18 تا 35 گذاشته میشه و تمامی اعداد داخل این بازه رو شامل میشه (حتی اگه هیچ رکوردی در این بازه نداشته باشیم) در صورتی که Repeatable Read چون صرفا به ازای رکورد‌های SELECT شده قفل گذاری میشه، که اگه فرض کنیم هیچ رکوردی در این بازه نداریم، هیچ قفلی هم ایجاد نخواهد شد

    بررسی نحوه عملکرد Serializable و استثنا‌های اون
    در سطح Serializable بر اساس یکی از حالات زیر قفل ایجاد میشه
    1- قفل Shared یا (S) روی کل Table
    اگه جدول Index ایی نداشته باشه بر روی کل Table قفل Shared Lock یا (S) میگذاره (فرقی هم نمیکنه شرط WHERE داشته باشیم یا نه)
    2- قفل Shared یا (S) روی رکورد (Row/Key)‌های Read شده
    اگه شرط WHERE مون بر روی یک ستون Index باشه و مستقیما با مقدار مقایسه کنه (مثل عملگر  = یا IN) روی رکورد (Row/Key)‌های Read شده قفل Shared Lock یا (S) میگذاره
    3- قفل RangeS-S روی رکورد (Row/Key)‌های Read شده
    اگه شرط WHERE مون بر روی یک ستون Index باشه و دستوراتی که بازه (محدوده) رو مقایسه میکنن (مثل عملگر < و > و... یا BETWEEN) روی سطح رکورد (Row/Key) قفل Key-Range Lock یا (RangeS-S) میگذاره
    4- قفل RangeS-S روی تمام رکورد‌ها (حتی Read نشده)
    اگه شرط WHERE نداشته باشیم یا شرط WHERE مون بر روی یک ستون Index نباشه روی تمام رکورد‌ها (Row/Key) حتی Read نشده، قفل Key-Range Lock یا (RangeS-S) میگذاره

    حال بر گردیم به سوال اولمون
    در نکته قبلی (شماره 5) دیدیم که در این مثال «خاص» میتونیم بدون استفاده از HOLDLOCK در کنار UPDLOCK کارمون رو انجام بدیم
    اما چی چیزی این مسئله رو «خاص» کرده؟
    چون شرط WHERE مون بر روی Index جدول (یعنی فیلد user_id) هست و با عملگر (=) که مستقیما مقایسه میکنه (و نه در یک بازه - محدوده)
    پس صرفا بر روی رکورد‌های Read شده (SELECT شده) قفل Shared Lock یا (S) گذاشته میشه دقیقا مانند کاری که Repeatable Read انجام میده (پس در این مورد خاص، سطح Repeatable Read و Serializable فرقی با هم ندارن)
    همچنین گفتیم که هینت UPDLOCK هم عمل قفل گذاری رو صرفا بر روی رکورد‌های Read شده ایجاد میکنه (پس در این مثال خاص کاملا مشترک و شبیه هستند) و به همین دلیل هست که میتونیم بدون نیاز به HOLDLOCK در کنار UPDLOCK به همون نتیجه برسیم
    در تصویر زیر Lock‌های ایجاد شده در 3 حالت رو مشاهده میکنین که هیچ تفاوتی با هم ندارن (از DMV سیستمی sys.dm_tran_locks کمک گرفتیم تا لیست Lock‌های در حال اجرا رو مشاهده کنیم)


    7- چه زمانی استفاده از HOLDLOCK در کنار UPDLOCK مفید هست؟
    زمانی که به Range-Key Lock نیاز داریم و میخوایم بر روی بازه (محدوده) رکورد‌های SELECT شده قفل بگذاریم (مانند Serializable) و نه صرفا خود رکورد‌های SELECT شده (مانند Repeatable Read)
    در واقع شرط WHERE مون بر روی Index و توسط عملگر مساوی هایی که مستقیما مقدار رو چک میکنین (مانند عملگر = یا IN) نیست  
    و چون این نکته ای ظریف و نیازمند دقت هست برنامه نویسان ترجیح میدن جهت محکم کاری بیشتر از HOLDLOCK در کنار UPDLOCK استفاده کنند و همین دلیل رایج بودنش هست
  • #
    هادی مزارعی هادی مزارعی
    ‫۱ ماه قبل، یکشنبه ۲۱ مرداد ۱۴۰۳، ساعت ۱۱:۵۳

    در EF Core 8 این امکان وجود داره که دستور ExecuteUpdate و ExecuteDelete رو بدون فراخوانی متد SaveChanges اجرا کنیم و عملیات بروزرسانی را مستقیم در بانک اطلاعاتی انجام بدیم. در مثال مایکروسافت در اجرای این دستورات مقدار version را به متد where داده است. در واقع اجرای متد ضمن بررسی Id باید مقدار version را نیز در نظر بگیرد. برای داشتن مقدار version باید یکبار به بانک اطلاعاتی درخواست ارسال کنم و این مقدار را یکبار از بانک دریافت کنم و بعدا به متد ExecuteUpdate پاس بدم. آیا راهی هست که برای اجرای دستورات مجبور به دریافت مقدار Version از بانک نباشم؟

    • #
      وحید نصیری وحید نصیری
      ‫۱ ماه قبل، یکشنبه ۲۱ مرداد ۱۴۰۳، ساعت ۱۲:۳۵

      خیر و بهتر است اگر نیاز به انجام چندین عملیات را در این بین دارید، «... به‌صورت صریحی، یک تراکنش مشخص، برای کل این مجموعه باز شود ...». قسمت «د) پیاده سازی optimistic locking» انتهای این بحث، فقط برای حالتی است که عملیات انجام شده، تحت نظر سیستم Tracking یک ORM قرار می‌گیرد و «Bulk operations» جزو آن نیست.