multithreading db

[ceeyt]

programimda veritabani (sql server) uzerinde islem yapan bir cok thread olusturuyorum.Her db isleminde diger thread leri bekletmeli miyim?

tecrubeli win32 programicisi arkadaslar goruslerini bildirirlerse sevinirim.


tesekkurler...

[Revne]

Cok iyi bir Win32 coder deilim..
Neden boyle bir yontem izlediğini ve problemini soylersen belki bir fikrim olabilir...

Kolay Gelsin...

[ceeyt]

soruyu su sekilde sorayim sanirim daha acik olur;
threadlerin senkronize edilmesi gerekliligi, ortak kaynak db(sql server 2000) oldugunda yine gecerli midir? yoksa dbms bunu kendi icinde bir kuyruk yapisina sokar mi?

hmm sanirim acilan baglantiyi ortak kaynak olarak gormem gerekiyor :garip:
kafam karisti :sus:

[myavuzselim]

Bence dbms'in bunu kendisinin halletmesi lazim. Zaten dbms'lerin gorevi bu gibi isleri halletmek degil mi?
Mesela bir webserver her db islemini tek thread'den halletmiyordur. Ama tabi bildigimden degil, sadece fikir yurutme.

[Kögüdey Meygen]

ms sql'i bilmiyorum ama mysql kullanırken her threadde init_thread gibi birşey demek gerekiyor.
büyük ihtimalle onda da senkronizasyon gerekir.

[Revne]

Veritabanı Sistemleri barındıkları verilerin okuma/yazma korulamalarını (kaynak kullanma politikalarini) kendi içlerinde yaparlar...

Bunun dışında birden cok Thread olayı sadece Veritabanini zorlar, yavaşlatir... Tabi bu Thread sayısı makul bir degerde olmalı... :)

Kolay gelsin

[mkarabulut]

Win32 programcısı değilim ama fikir yürütmek isterim :

Masaüstü programlama dillerinde (örneğin java'da) bir kaynağa erişim senkronize ediliyor, çünkü bir Thread işini bitirmeden diğeri girip kaynağı değiştirebiliyor ve eğer Thread'ler birbirlerinin ürettikleri sonuçlara bağımlı ise bu da kilitlenmelere sebep olabiliyor.

Aynı mantık ile DBMS'i kaynak olarak görürsek :

* Eğer thread'ler db üzerinde update v.s. yapıyorsa ve bir update bitmeden diğeri okuma yapmamalı ise, o zaman programcı senkronizasyonu sağlamalıdır.(Bkz: TRANSACTION/ROLLBACK/COMMIT veya mySQL için LOCK TABLE)

* Ama eğer thread'lerin veritabanını güncellemesi sonunda üretilen sonuçlar diğer thread'leri ilgilendirmiyorsa, o zaman senkronizasyona gerek yok.

* Thread'ler sadece okuma işi yapıyorsa yine senkronizasyona gerek yok.

NOT : Veritabanı zaten kendisine yapılan erişimleri kendisi senkronize edecektir, bu programcının işi değildir. Ama güncelleme yapılıyorsa bahsettiğim maddeler düşünülebilir.

[Revne]

Aynı mantık ile DBMS'i kaynak olarak görürsek :

* Eğer thread'ler db üzerinde update v.s. yapıyorsa ve bir update bitmeden diğeri okuma yapmamalı ise, o zaman programcı senkronizasyonu sağlamalıdır.(Bkz: TRANSACTION/ROLLBACK/COMMIT veya mySQL için LOCK TABLE)

* Ama eğer thread'lerin veritabanını güncellemesi sonunda üretilen sonuçlar diğer thread'leri ilgilendirmiyorsa, o zaman senkronizasyona gerek yok.

* Thread'ler sadece okuma işi yapıyorsa yine senkronizasyona gerek yok.

NOT : Veritabanı zaten kendisine yapılan erişimleri kendisi senkronize edecektir, bu programcının işi değildir. Ama güncelleme yapılıyorsa bahsettiğim maddeler düşünülebilir.

Veritabanlarınin kendi icinde, tıpki threadlerde kullandığımız gibi ceşitli LOCK / UNLOCK mekanizmaları vardır..Ilişkisel veritabanlarının cogu bu mekanizmaları kendileri yapar...Programci sadece Commit/Rollback gibi bir kaç komut ile bu olaylara mudahle edebiliyor.. Eger ilişkisel deilde Network yapısındaki bir veritabanıyla programlama yapıyorsanız (veritabanlarıyla SQL olarak deilde BINARY baglanıyorsanız...) bu LOCK mekanizmalarını goz ardı etmemelisiniz....

NOT: Ornek veritabanı sistemleri: RDM (Raima Database Manager), Velocis

Kolay gelsin...