RDBMS’lerde Deadlock

Bu flood’da da RDBMS’lerde Deadlock’lardan bahsedelim.

Flood’lar boyunca ACID’deki Isolation’dan sıklıkla söz ettik. Isolation özelliği ile, DB transaction’ları birbirini etkilemeden paylaşılan kaynaklar üzerinde tutarlılığı bozmadan çalışabilirler.

İki farklı transaction’ın A ve B tablolarındaki iki kayıt üzerinde işlem yaptığını ve işlemlerin verilen sırayla gerçekleştiğini düşünelim. İlk transaction A kaydını güncellemek üzere kilitlesin, A’yı güncellesin ve B’yi güncellemek üzere kilitlemek istesin fakat B o anda ikinci transaction tarafından güncellenmekte dolayısıyla da kilitlenmiş olduğu için ilk transaction ikincinin B üzerindeki işlemi bitirmesini beklesin.

Eğer burada ikinci transaction’ın B’den sonra almak istediği kaynak A ise oluşan durum Deadlock olarak adlandırılır çünkü ilk transaction A’yı almış B’yi beklemekte, ikincisi ise B’yi almış A’yı beklemektedir ve bu bekleyiş sonsuza kadar sürecek ve kaynaklar kilitlenecektir.

RDBMS’lerde Deadlock Detector’lar periyodik olarak koşarak sistemde Deadlock bulunup bulunmadığını kontrol ederler. Deadlock tespit ettikleri taktirde iki transaction’dan birini Rollback yapıp kaynakların serbest kalamasını sağlarlar.

Burada Victim (kurban) olarak seçilen transaction genellikle en az Rollback eforu olan transaction olur. Örneğin 2 saattir koşan bir SELECT sorgusu 100 ms koşan UPDATE sorgusuna göre kurban seçilebilir çünkü SELECT’te Rollback daha az maliyetlidir :-)

Örnekte kilitlenen kaynağı kayıt olarak verdik ama bu kaynak index de olabilir. Deadlock’ları önlemek için yapılması gerekenler çeşitlidir ve başka bir flood’da konu alacağız.