این تاپیک به معرفی سریع اتفاقی به نام Cascading Abort میپردازه.
یعنی حالتی که Abort کردن یک تراکنش، باعث Abort شدن تراکنشهای وابسته به اون میشه.
با یک مثال شرح میدهیم:
فرض کنید مقدار اولیه داده های x , y برابر 1 باشه.
فرض کنید تراکنشهای T1 , T2 ، اعمالی به این صورت و ترتیب انجام داده باشند :
حالا فرض کنید T1 رو Abort کنیم. پس مقدار x باید به مقدار اولیه خودش یعنی 1 برگردد.
بسیار خب ، حالا مقدار y ، چند هست ؟ توجه کنید که y رو تراکنش دوم دستکاری کرده و ما تراکنش اول رو ابورت کرده ایم.... آیا مقدارش 3 هست؟
جواب : در صورتی که دیتابیس بصورت cascaded عمل کند، y هم مقدارش به مقدار اولیه 1 برمیگردد.
علت ؟ توجه کنید که Read2(x) داریم. یعنی تراکنش دوم دارد x ی رو میخواند که توسط تراکنش اول نوشته شده . پس تراکنش دوم به تراکنش اول وابسته هست. پس وقتی تراکنش اول رو abort میکنیم، تراکنش دوم هم بصورت casecade وار!! ، abort میشود و این همان مفهموم cascading abort هست!
یعنی حالتی که Abort کردن یک تراکنش، باعث Abort شدن تراکنشهای وابسته به اون میشه.
با یک مثال شرح میدهیم:
فرض کنید مقدار اولیه داده های x , y برابر 1 باشه.
فرض کنید تراکنشهای T1 , T2 ، اعمالی به این صورت و ترتیب انجام داده باشند :
اینحا اندیس 1 مثلا در Write1 یعنی عمل write توسط تراکنش اول انجام شده ...
Write1 ( x, 2) , Read2 (x) , Write 2 (y,3)
حالا فرض کنید T1 رو Abort کنیم. پس مقدار x باید به مقدار اولیه خودش یعنی 1 برگردد.
بسیار خب ، حالا مقدار y ، چند هست ؟ توجه کنید که y رو تراکنش دوم دستکاری کرده و ما تراکنش اول رو ابورت کرده ایم.... آیا مقدارش 3 هست؟
جواب : در صورتی که دیتابیس بصورت cascaded عمل کند، y هم مقدارش به مقدار اولیه 1 برمیگردد.
علت ؟ توجه کنید که Read2(x) داریم. یعنی تراکنش دوم دارد x ی رو میخواند که توسط تراکنش اول نوشته شده . پس تراکنش دوم به تراکنش اول وابسته هست. پس وقتی تراکنش اول رو abort میکنیم، تراکنش دوم هم بصورت casecade وار!! ، abort میشود و این همان مفهموم cascading abort هست!
هیچ نظری موجود نیست:
ارسال یک نظر