DeadLock Sorunu

[tanerq]

Merhaba,

Sunucumuzdaki veritabanına bir çok client bağlı, herhangi bir client te problem yaşandığı zaman örneğin elektrik kesintisi gibi deadlock hatası alıyoruz. Bu deadlock hatasını durdurabilmek için sunucudaki veritabanı bağlantısını "Stop Start" mantığıyla düzeltebiliyorum. Fakat bu sefer sunucuya bağlı diğer clientlerin tümü hata veriyor.

Bu deadlock hatasını sunucudaki veritabanını kapatıp açmadan gidermenin bir yolu var mı ?

Bunun için araştırma yaptım ama bir türlü çözüm bulamadım "delete from mon$statements where mon$transaction_id = (deadlock hatasının verdiği transaction_id)" mesela bu şekilde çözüme ulaşan olmuş ama bende yine çalışmadı. Yardımlarınız için teşekkürler.

[cecihan]

aşağıdaki benimde kullandığım SQL aktif bağlantıyı kapatır .
DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = CURRENT_CONNECTION
denemedim ama bunla o bağlantıyı kapatıp tekrar bağlanırsanız tahminimce connection a bağlı transactionlarda kapanacaktır.

[serkan]

Evet malesefi firebirdün sinir bozucu özelliklerinden biride deadlock hatası, daha doğrusu hata demiyelimde mantığı diyelim..Çok kullanıcılı sistemlerde problem yaşatıyor.

Efendim siz kodlama mantığında yanlış yapmışsınız derseniz o olmaz. Döngüye girip tabloya 100 kayıt ekliycen, commitreatining olmadan makinada sorun çıkarsa, gitti komple sistem.. Ona bir time out filan koysalar 1-2 dk yapsak ..Beklesin herkes 2 dk ve son bağlantı ölsün..Niye yapmazlarki..

neyse

[Kuri_YJ]

Selamlar,

Malesef diyeceğim "Efendim siz kodlama mantığında yanlış yapmışsınız derseniz o olmaz. " Çünkü kodlama işin basit kısmıdır. İşin büyük bir kısmını tasarımda yaparsanız, bu tür sorunlarla karşılaşmazsınız. Ben Firebird'ü çıktığı günden, Interbase'i de, Firebird'ün çıktığı güne kadar kullandım, ve sadece bir defa Deadlock hatası aldım, onun sebebi de benim kodlama mantığımdan kaynaklandığını gördüm.

Şöyle bir şey söyleyeceğim, size örnek olması açısından.

85 Agent, 5 Supervisor, 2 Wallboard olan bir çağrı merkezi düşünün. Günde sistem ortalama 40,000-60,000 arasında telefon çağrısı yapıyor. Bu çağrıların takipleri de Firebird Database üzerinde tutuluyor. Birbuçuk yıldır kullanılıyor. Daha 1 defa bile Deadlock hatası almadık.

Bu arkadaşların tahmini saniyedeki ortalama transaction sayısını artık siz düşünün

Database tasarımları hakkında size, daha önceden yazdığım bir yazıyı öneriyorum. İsterseniz onu bir okuyun.

viewtopic.php?f=18&t=27521&p=153950&hil ... ns#p153950

bir de şunu bir okuyun

viewtopic.php?f=18&t=581&hilit=Performans

Ayrıca Firebird seminerimizi izleyin. Gerçi o baya eski bir seminer ama işinizi görür kanaatindeyim.

Kolay Gelsin
Adnan


Not : Yaklaşık arşivlerinde 10 milyona yakın kayıt da mevcut.

[HBV]

merhaba ....
Arkadaşım IB bileşenlerinin maselesef senelerdir çözülülemiyen sorunu bu? kodlarla filan çözülmüyor? geçici çözüm oluyor? boşuna uğraşma ancak DeadLock Sorununu FIBPlus,ve IBDAC ile aşabilirsin?ben bu bileşenleri projelerimde yıllardır kullanıyorum hiç bir problem yaşamadım,ayrıca FIBPLUS,da çift transaction kullanabiliyorsun ...kolay gelsin

[omurolmez]

Gözlemlediğim kadarıyla, bir istemcinin tcp-ip bağlantısı koparsa, o istemcinin başlattığı transaction 'lar sunucu tarafından rollback yapılıyor. Bu nedenle, elektrik kesintisi vb. nedenlerden dolayı deadlock almamanız gerekir (Sürümlerle alakalı mıdır bilmiyorum ancak Firebird 2.5 sürümünü kullanıyorum. Ayrıca ibx in Delphi 6 için çıkardığı güncellemeyi de yükledim).

Öte yandan, transaction larınızı sonlandırmıyorsanız veya ...retaining kullanıyorsanız, deadlock oluşma ihtimali artar.

Normalde, başlayan bir transaction en kısa sürede commit veya rollback ile sonlandırılmalıdır. Hem böyle yapmak, elektrik kesintisi vb arıza durumunda veri kaybını en aza indirir. Ayrıca transaction parametrelerinin de (wait | nowait) deadlock üzerinde etkisi var.

[serkan]

Trancastion parametreleri ile ilgili, hatta onların deadlock etkisi ile ilgili yabancı veya Türkçe bir makale bilen, gören varmı acaba.. Deadlock hatası gerçekten sıkıntı yaratıyor. Belki makale ile çözebiliriz.

[Kuri_YJ]

Selamlar,

Fazla vaktim yok ama birkaçını açıklayayım, Ancak bu iş sadece Firebird'e özgü bir konu değil ve geniş bir konu. Temel olarak Aratma yapmanız gereken konu "TRANSACTION ISOLATION LEVEL" veya "TRANSACTION HANDLING" veya "ISOLATION LEVEL" bu konular üzerine pek çok makale veya benzeri şey bulabilirsiniz.

Ama sıklıkla tercih edilen metod,

READ COMMITED : Sizin gönderdiğiniz komut başlamadan önce bitirilmiş olan tüm değişiklikleri görür. O anda işlem yapılan kayıtlardaki değişimleri görmez, eski hallerini (yani en son commit edilmişleri görür.

WAIT/NO WAIT : O anda işlem yapılmakta olan (yani başka transactionlar tarafından LOCK lanmış kayıtları beklesin mi beklemesin mi?)

Örnek Read Commited No Wait derseniz, hiç bir SELECT cümöleniz hiç bir Transactionı beklemez ve en son commit edilmiş olan datayı okur.

Read Commited Wait derseniz bu sefer de SELECT cümleleriniz okuma sırasında denk geldiği Transactionların tamamlanmalarını bekler.

Benim Genel Tercihim
READ COMMITED ve NO WAIT

Ama bu aslında sizin hem işinizin niteliğine hem de Database dizaynınıza bağlıdır.

Kolay Gelsin
Adnan

[HBV]

Merhaba...
Tüm bu anlatılanlar IBX bileşenleri için geçerli ,ben FIBPlus bileşenlerini kullanıyorum, ve bu konuda(Deadlock) hiç bir problem yaşamadım,deadlock konusunda net,de makaleler bulabilirsiniz ama sonuç değişmiyor? lock durumunda kod,lama mantığını çok iyi kullanmanız gerekiyor....tabi Kuri_YJ moderatorumuzun dediği gibi IBX bileşenleri kullanılacaksa işinizin niteliğine hem de Database dizaynınıza bağlıdır.