Transactionهای پیشرفته و سطوح level isolation

اینجا، مرز transactionها نیست. همانطور که قبلا در توصیف از خصوصیات ACID گفتم، transactionها، لزوما با دقسق ترین تعریف isolated هماهنگ نیست. دلیلش این است که وقتی شما transaction را ایجاد می کنید، می توانید سطح isolation یک transaction را configure کنید.

چرا می خواهید این کار را بکنید؟ performance. در حالی که isolation در تئوری بسیار جالب است، کمونیزم همه اینگونه بود. در واقعیت، قفل کردن گروهی از ردیف ها وقتی که یک transaction روی آن کار می کند، ممکن است به خاطر performance شدنی نباشد. لزوما نباید هر reader را از خواندن یک جدول متوقف کنید، زیرا transaction شما همه چیز را قفل می کند.

برای سبک کردن این نگرانی، .NET دارای قابلیت تعیین کردن سطوح isolation هنگام ایجاد یک transaction است. انجام این کار فقط نیاز به supply کردن یک System.Data.IsolationLevel value به متد BeginTransaction است. Valueهای در دسترس برای SQL عبارتند از:

ReadUncommitted: این، isolation نیست. هر کسی می تواند داده های قرارداده شده در جدول یا داده های update شده ای را که بلافاصله بعد از اینکه عبارت SQL باعث تغییر می شود، بخواند. نیازی به commit نیست. ممکن است این موضوع به فرایندی منجر شود که دارای داده های قدیمی (out-of-date) باشد. ممکن است از ورژنی از داده ها استفاده کند که از جدول باز گردانده شده اند.

ReadCommitted: این، کمی isolate تر است. در این مورد، یک transaction می تواند فقط داده هایی از جدول بخواند که قبلا commit شده اند. وقتی یک transaction می خواهد یک داده ها را update کند، نیاز به یک قفل (lock) مشترک (shared) روی آن داده ها دارد و (اگر با موفقیت قفل را بدست آورد) داده ها را update می کند. transactionهای خارج از آن transaction نمی توانند داده های آن جدول را update کنند. این، فقط کمی isolateتر است، اما یک عبارت SQL که دوبار در یک transaction اجرا شده است، می تواند نتایج متفاوتی را بازگرداند، اگر transaction دیگری، داده هایی را که عبارات SQL در بین دو عبارت اجرا می کنند، تغییر و commit کند. این، سطح isolation پیش فرض برای SqlTransaction است.

RepeatableRead: آرام آرام isolate تر می شود. در این مورد، یک قفل مشترک، روی تمامی داده های query شده در یک transaction اعمال می شود. این بدین معناست که هیچ transaction دیگری نمی تواند داده های استفاده شده در transaction شما را تغییر دهند.

Serializable: قفلها روی دامنه های (range) جداولی که استفاده می کنید قرار می گیرند و اجازه نمی دهند کاربرهای دیگر داده های شما را تغییر دهند یا ردیف های جدیدی اضافه کنند. این، isolateترین سطح isolation است.

در SQL Server 2005، یک سطح جدید isolation به نام snapshot isolation اضافه خواهد شد. در snapshot isolation، وقتی در یک transaction به ردیفها دسترسی پیدا می شود، version می شوند. این بدین معناست که زمانیکه یک transaction، به یک سری از valueها دسترسی پیدا می کند، ماندن آن valueها به همان صورت، تا زمانی که شما transaction را commit یا rollback کنید، تضمین می شود. Transactionهای دیگر که وسط transaction اول شروع شده اند، یک کپی از database اصلی می گیرند تا عملیات را روی آن انجام دهند. گر چه قبل از اینکه هر transaction تمام شود، SQL Server داده های اصلی را که داشتند رویشان عملیات انجام می گرفت را تست می کند تا مطمئن شود که همان داده های کنونی در database هستند. اگر اینگونه شود، transaction تمام می شود؛ وگرنه، transaction به همان حالت اول بازمی گردد و کاربر مجبور خواهد بود batch را دوباره امتحان کند.

نتیجه گیری

Transaction ها، برای چندین چیز دیگر نیز مفید هستند. اولا، راهی را جهت به حالت اول برگرداندن گروهی از عبارات SQL در اختیار می گذارد. به یاد داشته باشید که failure، می تواند بیشتر از یک error که برگردانده می شود، باشد. همچنین یک failure می تواند منطقی باشد - در مثال بالا، شاید حسابی که از آن پول منتقل می شد، پول کافی جهت انتقال ندارد. در این صورت، می توانید transaction را، هنگامی که به این واقعیت پی می برید، به حالت اول بازگردانید. دوما، آنها راهی را برای isolate کردن داده هایی که رویشان کار می کند در اختیار می گذارد، به طوری که دیگر در مورد surpriseها نگران نیستید. در همه موارد، باید سطح isolation را که واقعا نیاز دارید امتحان کنید و از تاثیرات performance همه آنها آگاه باشید.