işlem gören kaydın durumu.

[meron06]

İyi çalışmalar arkadaşlar.forumda en çok konuşuldu biliyorum ama bu sormak istediğim şeyden pek bahsedilmemiş.
örneğin bi urun tablomuz var .ve bu tablomuz üzerinde A kullanıcısı urun tablosunda bulunan bi kayıt üzerinde editleme işlemi yapıyor.A kullanıcısı bu kayda edit dediği anda (ibquery1.edit;) fire bird bu kayıdı başka kullanıcıların aynı anda silme ve edit işlemi yapmaması için kilitliyor.tabi doğal olarak başka kullanıcı bu kayıt üzerinde işlem yapmak isteyince deadlock hatası veriyor.

viewtopic.php?t=6969&highlight=deadlock bu başlık altında konuşulmuş ama anlayamadım .

Benim öğrenmek istediğim bi kaydı editlemeden yada silmeden önce o kaydın durumunu nasıl sorgulayabilirim.yani başka bi kullanıcı tarafından kullanılıp kullanılmadığını nasıl anlayabilirim.Cevaplarınız için şimdiden teşekkür ederim arkadaşlar.

[bgoktas]

Kod: Tümünü seç

try
query1.edit;
......
.....
..... 
query1.post;
except
 showmessage('birileri bu datayı kurcalıyor')//tabi tam olarak kurcalamıyorda olabilir.
end;

gerçek çözümün bu olmadığı muhakkak ama, maksat hata vermesini engellemekse alternatif olarak exceptionları kullanmanda fayda var.

[hbahadir]

bunun için en iyi çözüm bir application server yazıp, kaydı kullananların ben şu şu kaydı kullanıyorum demesi, kullanıcının bir kayıt üzerinde işlem yapacağı zaman sorması ve application server eğer kayıt kullanılıyor ise yok kardeş bu kayıtlar kullanılıyo demesini sağlamak bence. (Gözünü sevdiğimin BDE ' si neleri yapıyodu )

[meron06]

işallah daha kolay bi yolu vardır arkadaşlar bunun.yoksa büyük bi eksik gerçekten.

[fduman]

Bu konu daha öncede de geçmişti. Halen merak ediyorum yanıtını. Soru güzel.

[Terminator]

çok kullanıcılı bir sistemdesiniz, ilkel alışkanlıklarınızı aşmanız,
demokrasiyi öğrenmeniz lazım.

bir kaydı değiştirmek istiyorsanız değiştirmeye kalkın,
ya da FOR LOCK ile select edin. size o kaydı değiştirme izni verirse,
kayıt zaten locklı değildir sizin için locklanır, vermezse de sizden önce davranmıştır biri,
bunu da öğrenmiş olursun.
başka ne yapmayı düşünüyorsun?
yüzlerce kişinin her saniye bişeyleri değiştirme ihtimali olduğu bir sistemde
yaa bi bak bakem kilitli mi şu kayıt dedikten sonra, sen edit için locklayana kadar herkes aynı şeyi yapıyor olabilir.
bu tip sorulardan, hiçbir RDBMS, çok kullanıcı sistem, paylaşım eğitimi almadığınızı, PC-standalone-single task OS sistemlerini terketmek zorunda kalmanın sancısını çektiğinizi görüyorum.
ve, akıllı olmanız lazım gelen şeyleri hep atlıyorsunuz!
FB dünkü sistem değil! siz de dünyayı locklardan kurtaracak mucitler değilsiniz.
yazık bunu yapamıyor mu diyebileceğiniz en son sistem FB dür.
dünyada lock işleminin minimum olduğu ilk RDBMS FB dür.
bilir bilmez konuşup olayı türk usulü zekaya dayalı çamur atmaya çevirmeyin.
Ben merak ediyorum hangi sistemdir bu benim bilmediğim ve sizin lock sorunu yaşamadn herşeyi editleyip kullandığınız sistem? bi deyin hele...
Oracle? MSSQL? MySQL? DB2? Postgre? sybase?

[fduman]

Olay lock sorunu değil @Terminator. Lock'lı mıdır veya kim lock etmiştir, bunu öğrenmenin bir yöntemi var mı? Biraz araştırmıştım ama tatmin edici birşey bulamadım. Bizi aydınlatabilir misin?

[Kuri_YJ]

Selamlar,

Sanırım xbase'lerden gelen genel bir alışkanlık, LOCK edildiyse kim tarafından LOCK edildi. Zaten SELECT cümlesini FOR LOCK diyerek çektiğinde eğer sana sonuç döndürüyorsa zaten senin için kilitlemiştir ve sen Dataset'ini açık tuttuğun süre boyunca o kayıt senin için kilityli kalmış olacaktır. (Yanlış Anlatmıyorum değil mi Terminator?)

Ancak kimin kilitlediği konusunu ben de hiç incelemedim. Aslında tasarımı yaparken ben kayıt kilitleme mantığı ile bir şey yapmam, yapacak olursam da daha çok Manuel yöntemlere başvurarak bilgilerin sağlığını garanti altına almaya çalışırım.

Bu da bir tercih. Ancak DB bazında LOCK yapmak bana çok çekici görünmüyor. Kullanıcıları birbiriyle çatıştırmamak daha doğru olur. Yani birinin girdiği bir veriyi bir başkası editlemek isterse, onun bir sırası ve yetkilendirmesi, hiyerarşisi olmalı. Bu tarsarım boyutuyla daha çok ilgili.

Terminato'un dediği gib iaslında dünden sıyrılıp, bugüne ve yarına hitap edecek tasarımlar üzerinde kafa patlatmak ve elimizdekinin yeteneklerini bilip (bu hangi DB olursa olsun) hareket etmek tasarım yapmak gerekir diye düşünüyorum.

Ne dersiniz?

Kolay Gelsin

[fduman]

Valla ben yine de merak ediiyorum. Ayıp değil ya.

[Kuri_YJ]

Niye Ayıp olsun be Coder'im Lordum, ayıbı şimdi yapıyorsun bunu sorarak

[Terminator]

Olay lock sorunu değil @Terminator. Lock'lı mıdır veya kim lock etmiştir, bunu öğrenmenin bir yöntemi var mı? Biraz araştırmıştım ama tatmin edici birşey bulamadım. Bizi aydınlatabilir misin?

ilahi coderlordu,

Olay lock sorunu değil, ama locklu mudur, kim locklamıştır demek nasıl bir cümle?! ben ömrü hayatımda böyle şeyleri anlamadım.
ciciliano ne iş yapar umrumda değil ama bakire mi onu merak ediyorum demekten ne farkı var o cümlenin?

Madem teknik olarak olaya vakıf olamadınız, size sosyal mantıkla anlatayım olayı:
Kocaman bir parkta geziyorsunuz ve tuvaletiniz geldi, lök diye dalar mısınız umumi tuvalete?
ya da yoruldunuz oturup manzarayı izlemek, keyf yapmak istediniz, çöt diye gördüğünüz her banka oturabilir misiniz? bunları yapmak için sizde bir protokol, bir adap, bir ahlak, bir düzen, bir anlayış, bir saygı, bir mantık yok mu?
way efendim bank doluymuş, oturamıyorsun, ya da hela dolu kapıyı açamadın...
napıcan içerde çocuk varsa kapıyı mı kırıcan? ya da bankta yaşlı bir çift ya da zenciler oturuyorsa itekleyip sen mi oturucan?
tekrar yazıyorum,
çok kullanıcılı bir sistemdesiniz, ne kullanıcısı sayısında sınır var, ne de kayıt ne de işlem yapmada bir kısıt var.
bin bağlantının bininin de aynı kaydı aynı anda kullanma isteği bile olabilir.
tutarlılık, sağlamlık, bütünlük gibi kriterler vardır, buna ACID denir.
açılımını araştırın. önce öğrenmeyi öğrenin. teknolojiyi, bilimi, aklı, matematiği, mantığı öğrenin salak saçma ticari ürünleri ve onların komutlarını, vaatlerini vs değil. onlar sizi sadece bilinçsiz codecu yapar. hayal kurmak çok faydalıdır, ama hayallerinizdeki ölçüsüzlük, tutarsızlık ve denetimsizlik sizi bir yere götürmez. hayal sadece bir simülasyon sürecidir, oradan bir feedback ya da yararlı, kabul görecek bir sonuç üretemiyorsanız, o sadece zaman ve enerji kaybı vs dir.

FB de lock sistemi çok düzenli, yalıtılmış ve optimumdur.
sen bir kaydın locksız olduğu bilgisini alıp değerlendirene kadar binlerce
defa o kaydın lock durumuna geçip değişebileceğini düşünemiyor musun?
lock sizin için önemliyse, locklamaya çalışarak bunu denersiniz. yani helanın kapısını çalar ya da açmaya çalışırsınız. baktınız açılmıyor, gerisi malum. ha içerdeki ishal de olabilir, kısa bir iş için girmiş de olabilir, ya da aynaya bakmak için..
commit veya rollback mi olacağı belirsiz kayıtların kim tarafından locklı olduğunu bilmek normal bir program sürecinde ne işine yarayacak?
dirty-read mi yapmak istiyorsun? toplu hacetten yana mısın?
bir kayıt locka girdiğinde, hangi transcation tarafından loklandığını sistem bilir, ve gerekeni takip eder.
Ha şunu isteyebilirsiniz..
şerefsiz bazı kullanıcılar, lockladıkları kayıtlar varken giriş ekranlarını bırakıp yemeğe, toplantıya vs gidiyodur. diğerleri apışıp kalır, sistemi de restart edemezsin vs.. aslında edersin, FB takmaz, bozulmaz hiçbirşey,
işini yarım bırakan transactionlar iptal olur sadece.
bu sistemi düzgün tasarlayıp böyle saçmalıkları önlemek yazılımcı ve sistem mimarının görevidir.
kod yazmak değil, nasıl yazacağını bilmek önemlidir. kodlamanın kendisi angarya bir daktilografiden başka bişey değildir.
FB de event sistemini inceleyin, bu konularda da işe yaradığını göreceksiniz. ya da aynı connection üzerinden birçok transaction açıp
kritik lockları jurnalleyecek sistemler de geliştirebilirsiniz. hayal gücünün sınırı yok. mevcut imkanlardaki tutatsızlıkları ortaya koyamıyorsanız, onlara hakim olmayı öğrenin öncelikle.

[fduman]

Terminator söylediklerini anladım merak etme.

Merakım şundandır. Tut ki SAP R/3 gibi bir sistem tasarladık. Kullanıcı kritik verileri güncelleyecek. Gittik kaydı kilitledik. (SAP'de böyle) Kullanıcı bunu commit edene kadar ne olacak? O kayıt kilitli kalacak.

O esnada öngörmediğimiz şeyler oldu. Yıldırım düştü, kaos'da düzensizlik bir an değişti, yazılımda bug vardı, vs vs... Lock'ı kaldırmadık, kaldıramadık.

Tamam transaction timeout diyorsun. Güzel. O da çalışmadı bir şekilde. Sistemin bir thread'i iptal.

Bu kaydı kilitten kurtarmak istiyorum. Fakat hangi kayıt kilitli?

Debug etmek istiyorum. Kim kilitlemiş?

SAP'de bu gibi sorunlar olmuyor mu? Oluyor. Sistem lock atmış, kimse veri yazamıyor. Gidip debug ediyorsun, kim kilitlemiş hangi tabloda lock var bakıyorsun gereğini yapıyorsun.

İhtiyaç bundan ibarettir.

Ben yazdıklarından Firebird'den bu bilgiyi edinemeyeceğimi, sistem içinde bu kaydı saklayıp ne olduğunu çözeceğimi anladım. Tamam bu bilgi bana yeter.

Sağolasın.

[Terminator]

Terminator söylediklerini anladım merak etme.

Merakım şundandır. Tut ki SAP R/3 gibi bir sistem tasarladık. Kullanıcı kritik verileri güncelleyecek. Gittik kaydı kilitledik. (SAP'de böyle) Kullanıcı bunu commit edene kadar ne olacak? O kayıt kilitli kalacak.

O esnada öngörmediğimiz şeyler oldu. Yıldırım düştü, kaos'da düzensizlik bir an değişti, yazılımda bug vardı, vs vs... Lock'ı kaldırmadık, kaldıramadık.

Tamam transaction timeout diyorsun. Güzel. O da çalışmadı bir şekilde. Sistemin bir thread'i iptal.

Bu kaydı kilitten kurtarmak istiyorum. Fakat hangi kayıt kilitli?

Debug etmek istiyorum. Kim kilitlemiş?

SAP'de bu gibi sorunlar olmuyor mu? Oluyor. Sistem lock atmış, kimse veri yazamıyor. Gidip debug ediyorsun, kim kilitlemiş hangi tabloda lock var bakıyorsun gereğini yapıyorsun.

İhtiyaç bundan ibarettir.

Ben yazdıklarından Firebird'den bu bilgiyi edinemeyeceğimi, sistem içinde bu kaydı saklayıp ne olduğunu çözeceğimi anladım. Tamam bu bilgi bana yeter.

Sağolasın.

Coderlord,
SAP ne kullanıyor? hangi DB sistemini kullanıyor?
FB değil.
yıllar önce bir ara bazı işlerde kullanmaya kalkmışlardı borlandcılarla beraber.
Neyse, söylemek istediğini anlıyorum, ama bu olasılıkların FB sisteminde
oluşma ihtimalini hiç hesapladın mı? diyorum.
FB de bir thread tıkanacak ve FB çalışmaya devam edecek?
mümkün mü?
bir transcantion uzun süre inactive kalacak ve FB bu connectionı gebertmeyecek, bu mümkün mü?
FB de çekirdek bir bütündür, mimari bütündür, tutatlı ve eşgüdümlü çalışır.
MGA bir mimari diğer türlü çalışmaya devam edemez!
ama mysql, mssql, pervasivesql gibi recordmanagerlar üzerine SQL katmanı konularak geliştirilmiş sistemlerde durum farklı.
Senin söylediğin tarzdaki bazı sorunlar FB clasic serverda da yaşanıyor *nix sistemlerde kullanılırken. çünkü o sistemlerin mimarisi kötü. zombi prosesler, threadler, locklar kalabiliyor. kill etmek gerekiyor.
Çok lazım olan bişey değil istediğin şeyler bizde, FB genelde yönetimsiz ve ilgisiz yıllarca kendi kendine çalışır, bosh combi gibi yerini-varlıgını bile unutabilirsin.
FB de bağlantılar, transactionlar, userlar bellidir, API ile alınabiliyor.
ama öncelikli temel düzenlemeler yapıldıgı için senin istedğin tarzdaki
pratik yenilikler önümüzdeki yıldan itibaren gelecek.
mesela FB/IB de baştan beri create user xxx identified by xx gibi bir komut bile yoktur. userlar GSEC tooluyla ya da API yi kullanan herhangi bir araçla yönetilir. ama vulcanla bu değişti.
aynı şekilde, sistem bilgilerini gösteren sanal tablolar da devreye sokulacak yakında. yani console tabloları. DB mimarisinde bunları zorlaştıran hiçbirşey yok, sorun FB source koduydu ve o da yenilendi,
bundan sonra gelişmeler daha hızlı ve ekonomik olacak.
mesela bir SQL e TIMEOUT ya da default timeout verilecek ve
zombileşmesi (ki bunu zaten görmedim) uzunsürmesi, tıkaması önlenebilecek. vs vs.
Ama, Oracle ne zaman ne şekilde neresini geliştirirde bir trigger içinde
o table ı, yada onla ilişkili bir view vs sorgulama imkanı bulabilirim, allah bilir. ya da MSSQL daha commit veya rollback edilmemiş bir locklı kaydın
orjinal halini bana okumak için bile ne zaman verir, ha onlar yaptı pardon, ama oturması zaman alacak, ve bakalım bedeli ne olacak bu eğreti mimari çözümün. Bu sistemleri bildiğim için beklentilerini anlıyorum aslında, ama FB dünyasındasın, yanlış dayatılmış digital yargılarından arınmalı ve mirvanaya ermelisin. MSSQL, oracle kullanır gibi kullanırsan FB ü, bunları beklemen normal. FB den sonra da diğerlerini miden kaldırmayacak iyice öğrendikten sonra.
FB den kurtulabilmen için özel bir klinikte tedavi görmen ya da kendini budizme adaman gerekecek..

[sadettinpolat]

sen bir kaydın locksız olduğu bilgisini alıp değerlendirene kadar binlerce
defa o kaydın lock durumuna geçip değişebileceğini düşünemiyor musun?

bilgiyi degerlendirme sureci biraz da kodun nasıl yazıldığına bağlı.
mesela

kaydet dugmesinde yer alan kodlar şu şekilde olsun

Kod: Tümünü seç

KaydiDuzenlemekIcinAc
DegisiklikleriYap
Kaydet
If IslemBasarisiz KullaniciUyar

bunlar ardarda isleyen komutlar , dolayisiyla araya bir baska kullanicici girme ihtimali cok az. kaldiki araya bir baska kullanici girsin. yapilan islemlerin sonucunda ib/fb geriye sorunun ne oldugunu acikca belirten bir cok deger donduruyor. benim istedigimde eger bir lock yuzunden benim islemim basarili olamamışsa fb nin geriye xxxxxx gibi bi hata degeri dondermesi. bende bu hata kodunu isleyerek kullaniciya "uzerinde calistiginiz kayit bir baska kullanici tarafindan degistirilmekte oldugu icin isleminizi su an gerceklestirilemiyor. lutfen bir kac dakika sonra tekrar deneyin" mesajini vermek istiyorum.

bu sistemde bir kullanicinin bir kaydi kilitleyip yemege gitmesi ise zaten soz konusu degil

[Terminator]

Sizlere ilginç bir bilgi vereyim.
1970 lerden beri, Datatrieve,RDB/LN,GrotonDataBase,Interbase sisteminin mimarı olan ve tek başına da sistemi yazan Jim amcanın
Ürünü AshtonTate e sattıktan sonra Interbase den türettiği bir sistemi daha var. Netfrastructure. Dünyanın en modüler ve en mükemmel DB sistemidir. boyu 1 MB bir EXE. Java ile yazılır procedure ve triggerları yani içinde java VM de var. Record versioning işlemini RAM de yapar, diskte sadece asıl DB tutulur. Fulltext search en kolay syntaxa sahiptir.
ilgili kolonu tanımlarken yanına searchable yazmanız yeterli.
ararkenki sytaxı daha da basit.

http://www.ibdeveloper.com dan çıkan 3. sayıyı okuyun.

Jim amcanın tek başına birkaç ayda yaptığı şeyler borland 10 senede bir sürü mühendis ve kadroyla bile yapamadı. üstelik o kadroda yine jim amcanın çırağı elemanları bile kullandığı halde.

Yani FB ün bazı fonksiyonlar açısından çağın ve beklentilerin gerisinde kaldığını bütün FB cüler bilir ve kimse saklamaya çalışmaz.. ama bizim
sorunlar gelip geçici, yüzeysel sorunlar, ve FB artık ticari bir oyuncak değil, tekrar guruların bir sistemi. FB ün genleri sağlam, imaj nasıl olsa düzelecek.