Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Problem međusobne konkurencije podataka

[es] :: MS SQL :: Problem međusobne konkurencije podataka

[ Pregleda: 2929 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

itf
Zagreb

Član broj: 59794
Poruke: 993
*.dsl.iskon.hr.



+9 Profil

icon Problem međusobne konkurencije podataka12.06.2007. u 14:39 - pre 205 meseci
Da li je moguće u samom SQL serveru (2005) ikako riješiti problem data concurency-a, a da se to ne mora rješavati s klijentske strane kada pišem klijent aplikaciju? Inače, programiram u C++u (Builder 2006) pa ako netko ima rješenje i za taj slučaj molio bi da mi ga pošalje ([email protected]) ili da me bar uputi kako da to riješim.

Hvala
 
Odgovor na temu

dekibre
Dejan Mladenovic
Oslo, Norveska

Član broj: 21820
Poruke: 246
84.236.124.*

Sajt: dekibre.on.w802.net/index..


+4 Profil

icon Re: Problem međusobne konkurencije podataka12.06.2007. u 17:19 - pre 205 meseci
Ja radim u SQL Serveru 2000 a malo sam i radio u SQL Serveru 2005, ono što znam za SQL server 2000 a tiče se konkurentnosti podataka na samo sql serveru je setovanje isolation levela, ubedjen sam da je ista stvar i na SQL Serveru 2005 a možeš da proveriš u BOLu.

SET TRANSACTION ISOLATION LEVEL opcija

opcija može biti:
read uncommited
read commited
read reapetable
serializable


ono što je bitno je i šta možeš da radiš sa svakom od opcija

Code:
Kada neki korisnik pokrene transakciju i nije je jos zavrsio, postavlja se pitanje sta 
ostali korisnici koji zele iste resurse (konkurentni korisnici) mogu da rade i kakve podatke trenutno citaju.

Scenario
Prvi korisnik je zapoceo transakciju i lista npr. Slobodna mesta u avionu, moze da rezervise mesta 
ili otkaze rezervaciju,sta u medjuvremenu mogu da rade drugi konkurentni korisnici.

Prvo kakve podatke vide (one koji su u bazi ili one koji su u memoriji i nisu jos niti committed niti rollback 
[dirty pages])

Isolation level SELECT dirty
Read uncommitted DA
Read committed    NE
Read reapetable     NE
Serializable NE

Drugo sta mogu da rade konkurentni korisnici dok je transakcija prvog korisnika jos uvek ne zavrsena sa podacima 
koji zadovoljavaju iste kriterijume

Isolation level     UPDATE    DELETE    INSERT
Read uncommitted DA  DA  DA
Read committed    DA DA DA
Read reapetable    NE NE DA
Serializable NE NE NE             


Nadam se da ti je ovo trebalo.
You can fool some people sometimes,
But you can't fool all the people all the time. (Bob Marley)
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.237.*



+9 Profil

icon Re: Problem međusobne konkurencije podataka14.06.2007. u 08:28 - pre 205 meseci
Ali gdje uopće da namjestim taj isolation level??
 
Odgovor na temu

dekibre
Dejan Mladenovic
Oslo, Norveska

Član broj: 21820
Poruke: 246
84.236.124.*

Sajt: dekibre.on.w802.net/index..


+4 Profil

icon Re: Problem međusobne konkurencije podataka14.06.2007. u 17:49 - pre 205 meseci
Možeš da ga staviš u stored proceduru, pre nego što eksplicitno kažeš BEGIN TRANSACTION

Evo ti primera pa će ti verovatno biti jasnije

u QA otvori dva nova prozora za pisanje upita, to će simulirati kao da imaš dva konkurentna korisnika sa dve odvojene konekcije

u prvom prozoru iskopiraj sledeći kod, nadam se da imaš pubs bazu.

Code:
use pubs 
go

SET TRANSACTION ISOLATION LEVEL 
SERIALIZABLE 
GO

BEGIN TRAN
SELECT title FROM titles 
WHERE title_id LIKE 'BU%'


COMMIT TRAN

u drugom prozoru iskopiraj sledeći kod
Code:
use pubs
go
INSERT titles VALUES ('BU3000',          
                              'Itzik and His Black Belt SQL Tricks',   
                              'popular_comp', '0877', 39.95,                
                               10000, 12, 15000, null,                  
                              'Sep 15 2000')



E sada smo spremni da simuliramo dva konkurentna korisnika.

1. Izvrši prvi skript sve do COMMIT TRAN, taj deo ćemo kasnije da izvršimo.
2. Izvrši ceo drugi skript, videćeš da će se globus vrteti što znači da drugi korisnik čeka da upiše podatke u tabelu koji imaju isti kriterijum za primarni ključ kao select prvog korisnika tj. oba korisnika žele da rade nad istim resursima
3. Sada se vrati na prvi skript i izvrši samo COMMIT TRAN.
4. Vrati se na drugi skript i videćeš u messages da ti je upisan jedan red tj. insert je izvršen ali tek pošto je prvi korisnik commitovao svoju otvorenu transakciju.

E sad malo objašnjenja
Kada se izvši prvi korak to znači da konekciji prvog korisnika je setovan isolation level na serializable i da je otvorio transakciju gledanja odredjenih podataka. Kada drugi korisnik želi da radi nešto sa podacima koji zadovoljavaju kriterijum prvog korisnika tj. drugi korisnik pokušava da insertuje podatke koji počinju BU a za to vreme prvi korisnik je selectovao podatke sa like BU% i pri tome ima otvorenu transakciju i isolation level serializable, a ako pogledaš gornju tablicu u takvoj sitauciji konkuretni korisnik nemože ni da update, insert ni delete podataka već mora da čeka da prvi korisnik ili commituje ili rollbackuje otvorenu transakciju.
Kada se izvrši treći korak tj prvi korisnik je commitovao svoju otvorenu transakciju to znači da više ne drži lockove nad podacima tako da konkuretni korisnik može da izvrši svoj insert i nemora više da čeka.

Nadam se da će ti sada ovo malo više pomoći.


[Ovu poruku je menjao dekibre dana 15.06.2007. u 16:21 GMT+1]
You can fool some people sometimes,
But you can't fool all the people all the time. (Bob Marley)
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.237.*



+9 Profil

icon Re: Problem međusobne konkurencije podataka15.06.2007. u 07:58 - pre 205 meseci
Znači, ovo će vrijediti i u slučaju kada se neka aplikacija kao klijent spaja na bazu?
 
Odgovor na temu

dekibre
Dejan Mladenovic
Oslo, Norveska

Član broj: 21820
Poruke: 246
84.236.124.*

Sajt: dekibre.on.w802.net/index..


+4 Profil

icon Re: Problem međusobne konkurencije podataka15.06.2007. u 15:26 - pre 205 meseci
Rekao sam ti, najbolja varijanta ti je da stavljaš skript u stored procedure i u one procedure koje imaju veći prioritet stavljaš restriktivniji isolation level na taj način se obezbedjuješ da ti konkuretni korisnici nemogu "smetati". Samo dobro prouči gore navedenu tabelu i još bolje pročitaj u BOLu sve o setovanju isolation levela kako bi znao koji ćeš nivo kada da upotrebiš.

You can fool some people sometimes,
But you can't fool all the people all the time. (Bob Marley)
 
Odgovor na temu

aleksandarpopov
IT consultant
Senta

Član broj: 57172
Poruke: 484
*.sksyu.net.

Sajt: www.linkedin.com/in/aleks..


Profil

icon Re: Problem međusobne konkurencije podataka15.06.2007. u 16:04 - pre 205 meseci
@itf
Da razjasnimo nesto - da li se tvoje pitanje odnosi na :
1. Prevlacenje podataka na klijenta-promene na skupu podataka "offline" i zatim postovanju tih promena (ako je neko napravio izmene u podacima sto je ranije prevuceno - ovaj tip "konkurencije"... ) ili
2. Konkutrentan pristup pri samom citanju/pisanju na serveru?




RTFM
 
Odgovor na temu

dekibre
Dejan Mladenovic
Oslo, Norveska

Član broj: 21820
Poruke: 246
84.236.124.*

Sajt: dekibre.on.w802.net/index..


+4 Profil

icon Re: Problem međusobne konkurencije podataka16.06.2007. u 09:52 - pre 205 meseci
@aleksandarpopov

Ovo su dobra pitanja:
pogotovo batch update korisnika koji rade sa podacima u offline režimu.

You can fool some people sometimes,
But you can't fool all the people all the time. (Bob Marley)
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.237.*



+9 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 10:34 - pre 205 meseci
Citat:
aleksandarpopov: @itf
Da razjasnimo nesto - da li se tvoje pitanje odnosi na :
1. Prevlacenje podataka na klijenta-promene na skupu podataka "offline" i zatim postovanju tih promena (ako je neko napravio izmene u podacima sto je ranije prevuceno - ovaj tip "konkurencije"... ) ili
2. Konkutrentan pristup pri samom citanju/pisanju na serveru?


Ovako... općenito s Access bazom koristim prvi način. Znači, spojim se batchOptimistic. Uzmem podatke i obrađujem ih u memoriji, a samo na spremanju izmjena se nakratko spajam na bazu. Konkurentnost provjeravam iz klijent aplikacije.

E sad... To isto želim izvesti ali pomoći SQL Server baze, a gornji pristup kao za Access bazu mi ne radi. Meni je sasvim svejedno da li će to biti stalna konekcija ili batchOptimistic, ali želim nešto ovako:

aplikacija: "Dogodila se konkurencija među podacima. Želite li ponovo učitati dataset?"

i ako ja kažem YES, da mi se ponovo učita dataset. I tu je meni najveći problem jer ja ne znam kako bi sa klijent strane uspio detektirati konkurenciju.

Stoga, da li ja mogu u samoj bazi definirati ponašanje klijenata prilikom konkurencije podataka (ono što me najviše zanima), ili baš moram programski u klijent aplikaciji riješiti taj problem već nekako?
 
Odgovor na temu

aleksandarpopov
IT consultant
Senta

Član broj: 57172
Poruke: 484
*.sksyu.net.

Sajt: www.linkedin.com/in/aleks..


Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 11:15 - pre 205 meseci
BatchOptimistic ti mora raditi nezavisno od baze posto je to fakticki klijentski skup podataka tj. taj dataset nema veze da li je preko ADO komponenti recimo queryja prevuceno sa Access baze ili Ms sql ili PostgreSql ili Oracla potpuno je nebitno. Koliko je meni poznato, kada koristis batch opt. cuvaju se podaci u Originalnim podacima i o eventualnim izmenama (sve ovo ide preko parametara) u datasetu. Kada ti pokusas da postujes promene, ako je doslo do nekih promena (neko je promenuo originalne vrednosti bilo kog sloga tog dataseta u medjuvremenu) postovanje nece uspeti i bacice gresku koju ti mozes da uhvatis i obavestis korisnika sta se dogodilo ....
RTFM
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.237.*



+9 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 11:54 - pre 205 meseci
Citat:
aleksandarpopov: BatchOptimistic ti mora raditi nezavisno od baze posto je to fakticki klijentski skup podataka tj. taj dataset nema veze da li je preko ADO komponenti recimo queryja prevuceno sa Access baze ili Ms sql ili PostgreSql ili Oracla potpuno je nebitno. Koliko je meni poznato, kada koristis batch opt. cuvaju se podaci u Originalnim podacima i o eventualnim izmenama (sve ovo ide preko parametara) u datasetu. Kada ti pokusas da postujes promene, ako je doslo do nekih promena (neko je promenuo originalne vrednosti bilo kog sloga tog dataseta u medjuvremenu) postovanje nece uspeti i bacice gresku koju ti mozes da uhvatis i obavestis korisnika sta se dogodilo ....

U tome je problem:

1. Uhvatim grešku
2. Analiziram i detektiram da li se desila konkurencija i ako se desila...
3. Ponovo se spojim na bazu i uzmem friške podatke

Ovo bez greške radi na Access bazi, ali kod SQL servera prilikom točke 3 ne učita mi ništa.... Jednostavno ne radi. Stoga, ima li kakvo rješenje koje se može napraviti u samom SQL serveru?
 
Odgovor na temu

aleksandarpopov
IT consultant
Senta

Član broj: 57172
Poruke: 484
*.sksyu.net.

Sajt: www.linkedin.com/in/aleks..


Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 12:55 - pre 205 meseci
Ovo sto tebi treba nema veze sa bilo cime na sql serveru. Jedino tvoja klijentska aplikacija moze nakon sto je uhvacena greska tj. prikazana poruka korisniku da je doslo do konkurencije prilikom upisa u bazu, kazes mu da mora da otkaze promene i ako hoces mozes ponovo da okines upit koji ce uzeti sveze podatke, ali ti to moras sam isprogramirati na klijentu (mada ne znam zasto bi to radio - bolje ti je da samo obavestis korisnika da ga je neko preduhitrio u snimanju i da otkaze promene u batch-u, pa neka on odluci sta ce dalje)...
RTFM
 
Odgovor na temu

itf
Zagreb

Član broj: 59794
Poruke: 993
161.53.237.*



+9 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 12:59 - pre 205 meseci
Citat:
aleksandarpopov: Ovo sto tebi treba nema veze sa bilo cime na sql serveru. Jedino tvoja klijentska aplikacija moze nakon sto je uhvacena greska tj. prikazana poruka korisniku da je doslo do konkurencije prilikom upisa u bazu, kazes mu da mora da otkaze promene i ako hoces mozes ponovo da okines upit koji ce uzeti sveze podatke, ali ti to moras sam isprogramirati na klijentu (mada ne znam zasto bi to radio - bolje ti je da samo obavestis korisnika da ga je neko preduhitrio u snimanju i da otkaze promene u batch-u, pa neka on odluci sta ce dalje)...

Nije to samo tako jednostavno jer kada program javi da je došlo do konkurencije zaključa mi problematični zapis i prisiljen sam refreshati cijeli dataset. Uglavnom, nije bitno. Ako se ništa ne može na server strani onda ću već nešto smisliti za aplikaciju. Hvala
 
Odgovor na temu

dekibre
Dejan Mladenovic
Oslo, Norveska

Član broj: 21820
Poruke: 246
84.236.124.*

Sajt: dekibre.on.w802.net/index..


+4 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 16:45 - pre 205 meseci
Ja lično nisam radio ovo što ću ti predložiti ali sam negde pročitao da su tako neki radili.

Da bi održao konkuretnost podataka koje u batchu prebacuješ sa klijenta a da ti se obeležje svakog reda nalazi na serveru, stvarno nemogu da se setim gde sam ovo pročitao, tako što se željenoj tabeli doda jedna kolona tipa timestamp koja se menja automatski svaki put kada se podaci updateuju. Tako da kada pokopiš podatke ti za svaki red imaš i njegov timestamp koji si isčitao a kada podatke vraćaš pre nego što izvršiš update proveriš da li se timestamp u medjuvremenu promenio.
You can fool some people sometimes,
But you can't fool all the people all the time. (Bob Marley)
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 16:50 - pre 205 meseci
Jeste, može da se doda timestamp kolona u svaku tabelu.

Kada se radi update samo se proveri da li je to polje promenilo vrednost. Ako jeste, znači da je neki drugi korisnik već izmenio isto polje pa izmene treba odbaciti.

Ovo se još naziva i "optimistic concurrency."
Commercial-Free !!!
 
Odgovor na temu

aleksandarpopov
IT consultant
Senta

Član broj: 57172
Poruke: 484
*.sksyu.net.

Sajt: www.linkedin.com/in/aleks..


Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 17:39 - pre 205 meseci
Citao sam i ja o tome to je ok resenje ako se ne koriste datasetovi, ali malo mi je suvise posla ako isti rezultat mozete dobiti sa manje posla - barem kada se koriste datasetovi, kada se stavi u ADO na batch optimistic kursor ili u ADO.NET-u Optimistic concurrency kada se generise WHERE uslov za UPDATE naredbu on ne doda samo vrednost primary key-a u uslov vec dodaje i @oldValue (prva ucitana) za sve kolone i ako se ne slazu vrednosti - znaci da je neko vec nacinio izmene - sve u svemu dobija se isti rezultat.

[Ovu poruku je menjao aleksandarpopov dana 18.06.2007. u 18:56 GMT+1]
RTFM
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: Problem međusobne konkurencije podataka18.06.2007. u 17:53 - pre 205 meseci
^Pa jeste.. isto je.

Ako se doda timestamp, onda se procita vrednost tog polja prilikom čitanja zapisa. I to je onda "oldValue". Kada radiš update, trebaš da taj "oldValue" uporediš sa trenutnim, tj. otprilike

UPDATE table1 (ime, prezime) VALUES ('pera', 'peric') WHERE kupacID=17 AND time_stamp = @time_stamp_old

I to je to.

Ako je polje time_stamp (koje je tipa timestamp) u međuvremenu izmenjenou, neće ni doći do apdejta zbog uslova u WHERE. Ako UPDATE uspe, time_stamp se automatski postavlja na novu vrednost.

Pozdrav.
Commercial-Free !!!
 
Odgovor na temu

[es] :: MS SQL :: Problem međusobne konkurencije podataka

[ Pregleda: 2929 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.