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.

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.

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.



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

<sub>[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]</sub>

@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).

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

Pozdrav,
Vladan

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.

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..

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

Pozdrav,
Vladan

@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.