WITHROLLBACK IMMEDIATE komutuyla diğer transaction’ları rollback ederek işleminizi gerçekleştirebilirsiniz.

Bu Level’da artık selectler beklemek zorunda kalmayacaktır. Statament bazlı read tutarlılığı sağlar. Her select statement’ı başladığı anda, select edilen kayıt başka bir transaction tarafından update oluyorsa ve update henüz commit edilmemişse, select, update’in commit olmasını beklemeden datanın en son commit edilmiş haline ulaşır. Statement bitene kadar bu değeri görmeyi garanti eder. Fakat bu garantiyi transaction bazlı sağlamaz. Transaction içersindeki her statement başlangıcında bu kontrolü yapar. Mesela bir transaction içersinde iki select statement’ı olduğunu düşünelim. İlk select statement’ı biraz önce bahsettiğim gibi, datanın en son commit edilmiş halini okumuş olsun. İkinci select başladığı anda okunmak istenen veri commit olmuşsa iki select farklı değerleri okuyacaktır. 

Peki  verinin en son commit edilmiş halini okuma işlemi nasıl gerçekleşiyor?

RCSI, bu özelliği row versioning ile sağlıyor. Yani veriyi tempdb’yi kullanarak versiyonluyor. Bir update işlemi olduğunu düşünelim. Veri update işlemi gerçekleştiğinde(henüz Commit yok) verinin en son commit edilmiş hali (update işlemi öncesi) tempdb’de saklanıyor. Verinin yeni halinden, temdb’ deki versiyonuna link oluşturuluyor. Bu şekilde başka bir transaction içersinden bir select isteği geldiğinde tempdb’deki en son commit edilmiş halini okuyabiliyor. Bu okuma şekline Optimistic Read diyoruz. RCSI’ ı veritabanında enable ettiğiniz anda row versioning işlemi başlıyor. Her gelen update ve delete işlemi (bazı insert işlemleride)versiyonlanıyor. Bu özelliği sağlayan row versioning bilgisini tutabilmek için veritabanındaki her etkilenen satıra 14 byte ekleniyor. Bu Isolation Level’da, verinin tempdb üzerinde versiyonlaması yapıldığı için update, delete ve bazı insert’ler sistem kaynaklarını daha yoğun kullanabilirler. Fakat tempdb daha çok memory kullanırsa bu dezavantajı minimuma indirgenebilir. Ayrıca bu özelliği set etmeden önce tempdp’ye binecek yükten dolayı tempdb’nin bu yükü taşıyabileceğinden emin olmalısınız. 

Şimdi daha önceki örneklerimize dönelim. Lost Update, Non-repeatable read ve Phantom Read, Read Committed’da olduğu gibi bu Isolation Level’da da devam edecektir.

Dirty Read: READ COMMITTED’dan farklı olarak ikinci session’da, select beklemeden en son commit edilmiş halini okuyacaktır. Hem dirty read yapmamış hem de beklememiş olacaktır.

2) SNAPSHOT: Row versioning ile çalışan diğer Isolation Level’dır. RCSI’dan farklı olarak transaction bazlı read tutarlılığı sağlar. Bu özelliği sayesinde bir çok concurrency sorununu çözmüş olacaktır. Örneklerimizi tekrarladığımızda bu sorunları nasıl aştığını göreceğiz. RCSI da bahsettiğim örnekteki gibi ,ilk select statement’ı, datanın en son commit edilmiş halini okumuş olsun. İkinci select başladığı anda okunmak istenen veri commit olmuşsa bile, ikinci select ilk select ile aynı değeri okur.  Veritabanı bazında aktif edilmesi gerekir. Aşağıdaki script yardımıyla aktif edebilirsiniz.

ALTER DATABASE [AdventureWorks2012] SET ALLOW_SNAPSHOT_ISOLATION ON
GO

RCSI’dan diğer farkı ise veritabanında aktif edilmesine rağmen tüm transactionlar için geçerli değildir. Sadece SET TRANSACTION ISOLATION LEVEL SNAPSHOT ile belirttiğiniz transactionlar için geçerlidir. Bu nedenden dolayı uygulama bu Isolation Level’a geçerken iş yükü artacaktır.  Dikkat edilmesi gereken önemli bir nokta olarak;veritabanı bazında SNAPSHOT’a izin verdiğiniz anda transaction’larınızda SNAPSHOT’ı kullanmasanız bile update,delete ve bazı insert’ler versiyonlanmaya başlayacaktır. Bu işlemde tempdb’de yoğun kullanıma sebep olacaktır. Şimdi örneklerimizi SNAPSHOT Isolation Level’da gerçekleştirelim. Dirty Read örneği RCSI Level’ındaki gibi gerçekleşecektir.

Non-repeatable read: REPEATABLE READ Isolation Level’ından tek farkı ikinci session beklemeden işlemini yapacak, ilk session iki select’te de aynı sonucu döndürmeye devam edecektir. Gördüğünüz gibi transaction bazlı read tutarlılığı sağlaması Non-repeatable read olmasını engelledi.

Lost update Örneklerimizi çalıştırdığımızda ikinci session’ın işlemi tamamladığını ve 1100 değeri döndürdüğünü görüyoruz. İlk session ise aşağıdaki gibi hata alıyor. 

Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table ‘Production.Product’ directly or indirectly in database ‘AdventureWorks2012’ to update, delete, or insert the row that has been modified or deleted by another transaction. Retry the transaction or change the isolation level for the update/delete statement.

Gördüğünüz gibi ilk commit olan transaction’ın ezilmesine izin vermedi. Fakat veriyi ilk okuyan session conflict oldu.

Phantom Read: SERIALIZABLE Isolation Level’den farklı olarak ikinci session ilk session’ın bitmesini beklemeden insert yapabildi. Fakat konunun başında bahsettiğim gibi, SNAPSHOT transaction bazlı read tutarlılığı sağladığı için, ikinci select ilk selectle aynı değeri okudu. Bu şekilde Phantom Read engellenmiş oldu.

Serimizin 3. makalesinde RCSI ve SNAPSHOT Isolation Level’ların daha derinliklerine ineceğiz. Kısıtlamalarını ve farklarını inceleyeceğiz. Son olarak’ta bu Isolation Level’ları kullandığımızda tutarsızlığa neden olabilecek durumları analiz eden 3 örnek yaparak Isolation Level makale serisini sonlandıracağız.