Formulari i 'race condition'

Šta se u praksi pokazalo kao najbolje rešenje za sprečavanje 'race condition' situacije kod editovanja formulara ?

Primer:

Administrator 1 je otvorio formu stranicu kojom posmatra sadržaj nekog zapisa iz baze, i počinje da ga edituje, jer mu se recimo ne sviđa naslov artikla.

Administrator 2 zatim otvara na svom računaru istu tu stranicu i gleda sadržaj istog tog zapisa iz baze, jer recimo želi da cenzuriše psovku iz teksta artikla.

Admin 1 je izmenio naslov i pritiska dugme 'Save' i snima nov sadržaj formulara u bazu.

Admin 2 završava cenzurisanje teksta i pritiska 'Save'. Time u stvari on pregazi naslov teme originalnim sadržajem i tako slučajno anulira efekat prvog admina.

Kako je to rešeno u nekim većim sistemima ?
Zaključavanje editovanja zapisa ne dolazi u obzir.

Potpis

_{"The quieter you become, the more you are able to hear."}
Blog | PowerCMS

moje mišljenje je da se upiše u bazu da admin 1 edituje to i to i onda na save adminu 2 kaže da je admin 1 menjao ili menja stranicu i pita ga da li sigurno želi da pregazi promene. tako radi wordpress

http://en.wikipedia.org/wiki/Database_transaction

Potpis

Nebojša Đorđević - nesh
http://younify.nl

Imaš nekoliko varijanti:

1) Prva je ovo što je PHPovac predložio, tipa da napišeš poruku "Korisnik X edituje ovaj formular", pa pustiš čoveka da se dovikuje sa X-om o tome šta da se radi.
2) Ono što ja prefereriram da uradim je sledeće:

Svaka tabela ima "modified" polje (ON UPDATE CURRENT_TIMESTAMP varijanta). Kada čovek otvori stranicu, tj. kada imaš GET poziv (ako je tako rešeno), sačuvaš vreme tog događaja. Kada klika na Save, proveriš "modified" polje. Ako je $modified > $otvaranje_formulara, prikažeš stranicu koja opisuje konflikt. Npr. prikažeš paralelno dva formulara, jedan sa izmenama koje je čovek hteo da izmeni, drugi sa aktuelnim podacima (koji su oni koje je drugi admin u međuvremenu sačuvao).

Onda čoveku daš opcije koje bi ti dao bilo koji versioning system:

- mogućnost da koristi postojeće izmene, tj. da odbaci svoje
- mogućnost da koristi svoje izmene i mogućnost da ih menja, da bi prilagodio onome što vidi kao aktuelne informacije.

Ova varijanta je dobra jer ne moraš da diraš bazu. Sve izmene čuvaš u sesiji (tj. samo ih prebacuješ iz poziva u poziv) i porediš sa stvarima u bazi. Možeš i u nedogled da vrtiš, tj. ako 5 ljudi radi na istom formularu, ti uvek za svakog proveravaš kada je poslednji put otvorio formular i kako se poredi sa "modified" poljem.

3) Konačno, možeš da napraviš ceo versioning sistem. Umesto jednog reda za jedan unos u bazi, imaš N redova, svaki sa timestampom i najnoviji timestamp je aktuelna verzija. Onda korisnici mogu da roll-backuju izmene, da ih uporede itd. Ako očekuješ puno takvih konflikta, onda je to prava stvar, ali i najkomplikovanija.

@nesh
Kako? Moze li simple primer koda?

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

Prilično sam siguran da se to ne može rešiti transakcijama. One imaju drugu svrhu. Npr:

Hoćeš da updateuješ tabelu A i onda u tabelu B da uneseš, npr. informaciju da si updateovao nešto. Ako uradiš čisto (presudocod):



Ovo pod 2) će se izvršiti čak i ako ovo pod 1) nije uspelo. Ako je ovo pod 1) uspelo, onda će postojati trenutak u vremenu kada će tabela A biti ažurirana, ali tabela B neće.
Onda to rešiš sa (opet pseudokod)



Kada uradiš COMMIT, OBA querya će biti sačuvani u bazi. Kada uradiš ROLLBACK, kao da se ništa nije desilo...

Dakle, neprimenjivo za zadati problem :)

@cabrilo
Znam sta su transakcije i znam da ne moze ovaj problem da se resi transakcijam, zato i pitam za primer koda a ne samo povrsno procitana teorija :)

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}