[es] - Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

damso
IT obuka i savjeti, u sopstvenom aranžmanu, uz kafu ..
Doboj-Novi Sad-ponekad BL

Član broj: 78853
Poruke: 145
*.dialup.neobee.net.

Sajt: www.do-2.net

Profil

Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{27.12.2005. u 20:39}

Ako vishe klijenata zahteva npr.webStranu,onda se pokrece vishe php skriptova tacnije jedan se pokrene vise puta.E sad to su kao neki threads ili ti procesi/ili niti.

Citao sam da se taj deo pristupa bazi zove TRANSAKCIJE ali nisam nasao dovoljno literature..
Da li o tome mora da brine PHP/(..script) programmer ili dataBase administrator ili sam RDBMS?

Inache razumem mehanizme sinhronizacije tipa Semaphores,Monitors,ConditionVariables,..ali me interesuje da li moram ja(tj.neki script coder) da o tome misli ili sam RDBMS.

hvala

^{27.12.2005. u 20:39}

noviKorisnik

Član broj: 13216
Poruke: 4513
*.ADSL.neobee.net.

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{27.12.2005. u 20:52}

Mislim da bi bilo dobro da pokušaš da definišeš neki primer, da se uoči kritična oblast i da potom vidimo šta bi moglo da pomogne.

^{27.12.2005. u 20:52}

damso
IT obuka i savjeti, u sopstvenom aranžmanu, uz kafu ..
Doboj-Novi Sad-ponekad BL

Član broj: 78853
Poruke: 145
*.dialup.neobee.net.

Sajt: www.do-2.net

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{27.12.2005. u 21:34}

Pa recimo vise korisnika odjednom hoce da promeni nesto na wikipediji koju svi mogu da menjaju..

Dodje osoba A i kaze SELECT x FROM Table WHERE...
I sad dodje osoba B i kaze,ne znam,UPDATE FIELD (x,newvalue) ili kako vec ide u SQLu,
i to tako nekako da je proces koji sluzi osobi A prekinut tj.pauziran bash unutar izvrsenja funkcije SELECT,dakle pocela se izvrsava a nije uspela da procita iz baze.(znaci shvatimo da je funkcija SELECT tu valjda kriticna obl?) i B promeni vrednost x
a onda se nastavi proces A i nastavi se funkcija SELECT tamo gde je stala..i ona umesto starog x vrati novi x.A recimo to nije smelo da se desi.

DA LI f-ju SELECT obradjuje kao kriticnu:

1)RDBMS,znaci izvrsavanje samog upita je napravljeno tako da Operativni sistem ne sme da prekine tu f-ju napola..
2)Programer,znaci ja sednem pa akd pisem sql upit svaki put kda pisem SELECT upakujem ga sa DOWN(Mutex) UP(MUTEX)

3)Neki administrator koji odlucuje kome ce od gornje dve "instance" da poveri taj zadatak.

^{27.12.2005. u 21:34}

valeksa
Vladan Aleksic
Beograd

Član broj: 33124
Poruke: 42
195.252.89.*

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{27.12.2005. u 23:06}

Citat:

damso:
Dodje osoba A i kaze SELECT x FROM Table WHERE...
I sad dodje osoba B i kaze,ne znam,UPDATE FIELD (x,newvalue) ili kako vec ide u SQLu,
i to tako nekako da je proces koji sluzi osobi A prekinut tj.pauziran bash unutar izvrsenja funkcije SELECT,dakle pocela se izvrsava a nije uspela da procita iz baze.(znaci shvatimo da je funkcija SELECT tu valjda kriticna obl?) i B promeni vrednost x
a onda se nastavi proces A i nastavi se funkcija SELECT tamo gde je stala..i ona umesto starog x vrati novi x.A recimo to nije smelo da se desi.

Ne poznajes web tehnologiju. Ovaj primer koji si naveo NE MOZE da se desi jer je ova tehnologija bazirana na request-response principu i svaki korisnik ima svoj thread da pojednostavim tako da jedan thread ne moze da prekida drugi. Oni su nezavisni u najvecem broju slucajeva. Naravno, ovo vazi ako imamo jednu instancu web servera i jednu instancu baze.

Citat:

DA LI f-ju SELECT obradjuje kao kriticnu:

1)RDBMS,znaci izvrsavanje samog upita je napravljeno tako da Operativni sistem ne sme da prekine tu f-ju napola..
2)Programer,znaci ja sednem pa akd pisem sql upit svaki put kda pisem SELECT upakujem ga sa DOWN(Mutex) UP(MUTEX)

3)Neki administrator koji odlucuje kome ce od gornje dve "instance" da poveri taj zadatak.

Sta moze da se desi:
1. SELECT se izvrsio pre UPDATE. klijent B ce dobiti <staru vrednost>
2. SELECT se izvrsio posle UPDATE. klijent ce dobit <novu vrednost>

Na programeru je da resi ovu sitaciju kako njemu odgovara.

BTW, transakcije se obicno koriste kada imas multitable update koji treba da se zavrsi kao jedna celina. Ako se prekine imas mogucnost ROLLBACK-a na pocetno stanje.

Pozdrav,
Vladan

_{[Ovu poruku je menjao valeksa dana 28.12.2005. u 00:10 GMT+1]}

_{[Ovu poruku je menjao valeksa dana 28.12.2005. u 00:10 GMT+1]}

^{27.12.2005. u 23:06}

_owl_
Centar - BG

Član broj: 318
Poruke: 989
*.vdial.verat.net.

Sajt: home.drenik.net/~owl

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{28.12.2005. u 01:11}

@valeksa
Postoji bitna razlika izmedju procesa (ili instance servera) i niti (kojih moze biti vise u okviru jednog procesa), sve sto si napisao u prvom pasusu uglavnom nije tacno.
@damso
RDBMS obicno vodi racuna o tome, u principu je moguce programski postaviti nivo izolovanosti transakcija.
Primer koji si dao podrazumeva upotrebu "dugih" transakcija koje se mogu resiti na razne nacine (proguglaj malo o optimistickom i pesimistickom lockovanju).

Owl

^{28.12.2005. u 01:11}

valeksa
Vladan Aleksic
Beograd

Član broj: 33124
Poruke: 42
195.252.89.*

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{28.12.2005. u 01:30}

Citat:

_owl_: @valeksa
Postoji bitna razlika izmedju procesa (ili instance servera) i niti (kojih moze biti vise u okviru jednog procesa), sve sto si napisao u prvom pasusu uglavnom nije tacno.

Znam to, ali sam hteo 'pojednostavljenim' :) recnikom da objasnim da upit jednog korisnika ne moze da prekine drugi.

Pozdrav,
Vladan

^{28.12.2005. u 01:30}

_owl_
Centar - BG

Član broj: 318
Poruke: 989
*.vdial.verat.net.

Sajt: home.drenik.net/~owl

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{28.12.2005. u 14:24}

Gresis ovaj silno gresis, normalno da moze.
Dobar primer bi bio slucaj kada se vrsi rucno zakljucavanje tabela. Za simulaciju zagusenja se izmedju SQL upita mogu postaviti proizvoljne pauze (pomocu sleep()). U ovom slucaju kada bi na server stigla dva zahteva za izvrsenje skripte jedan bi morao da saceka da se izvrsi drugi.

Owl

^{28.12.2005. u 14:24}

damso
IT obuka i savjeti, u sopstvenom aranžmanu, uz kafu ..
Doboj-Novi Sad-ponekad BL

Član broj: 78853
Poruke: 145
*.dialup.neobee.net.

Sajt: www.do-2.net

Profil

moze ili ne moze?

^{28.12.2005. u 23:11}

Hajde sada da napravimo anketu:

MOZE ili NE MOZE?(da procesor prekine SQL funkciju)

za sada imamo samo jedan glas ZA

Bilo bi zanimljivo videti konkretne primere..

^{28.12.2005. u 23:11}

valeksa
Vladan Aleksic
Beograd

Član broj: 33124
Poruke: 42
195.252.89.*

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{28.12.2005. u 23:21}

Citat:

_owl_: Gresis ovaj silno gresis, normalno da moze.
Dobar primer bi bio slucaj kada se vrsi rucno zakljucavanje tabela. Za simulaciju zagusenja se izmedju SQL upita mogu postaviti proizvoljne pauze (pomocu sleep()). U ovom slucaju kada bi na server stigla dva zahteva za izvrsenje skripte jedan bi morao da saceka da se izvrsi drugi.

Pa da, to i pricam, da saceka a ne da prekine.

Pozdrav,
Vladan

^{28.12.2005. u 23:21}

The Sekula

Član broj: 53829
Poruke: 76
*.eunet.co.yu.

Sajt: www.sekulovic.net

Profil

Re: Multithread pristup bazi:(synchronization,dead locks) ko vodi racuna o tome?RDBMS?

^{29.12.2005. u 08:24}

@damso

RDBMS radi deo posla, deo posla moras da odradis ti.

prosto

SELECT x FROM t

UPDATE t SET x= 'y'

moze dovesti do problema. Vecina RDBMS-ova ima posebu sintaksu koja ti omogucava da zakljucas zapis da niko ne moze da ga promeni pre commit-a tvoje transakcije. Sintaksa je obicno

SELECT x FROM t FOR UPDATE

Ono o cemu jos treba voditi racuna je da ponekad i pored iste sintakse razliciti RDBMS-ovi ne ponasaju se svi na isti nacin.

Ako ne postoji ovakva sintaksa u samom RDBMS-u ili je ponasanje RDBMS-a na ovakvoj sintaksi ne odgovarajuce, moguce je i eksplicitno sam zakljucati polje pre select-a.

UPDATE t SET x=x

SELECT x FROM T

UPDATE t SET x= 'y'

Pored ovog pristupa sa zakljucavanjem (tzv pesimistic locking), moguc je tzv. optimistic locking, gde nista unapred ne zakljucavamo vec prilikom update-a radimo proveru da ne gazimo tudje izmene

UPDATE t SET x='y' WHERE x='z' AND id=... (gde smo 'z' procitali sa select-om)

a onda proveravamo da li smo azurirali ocekivani broj zapisa i ako nismo rollbackujemo transakciju. Medjutim u takvom pristupu moramo imati i neki nacin da identifikujemo zapise jednoznacno (zato stoji ono AND id=...) da ne bi azurirali tacan broj zapisa ali pogresnih.

If Images - Royalty Free and Rights Managed
images

^{29.12.2005. u 08:24}