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

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?

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 :)

Imas u tabeli koju editujes polje version koje svaki put kada update-ujes inkrementiras za jedan.

npr. kada popunjavaš formu uradi sledeći upit.



Dobiješ neki odgovor od baze
username: pero
ime: petar
prezime: peric
version: 21

Kad završiš editovanje i klikneš na Save uradiš sledeće:


Nakon ovoga provjeriš koliko je kolona updateovano, ukoliko je to 0 onda znači da je neko u međuvremenu to ažurirao i da je verzija uvećana, da tvoj WHERE uslov ne pije vode i obavjesti korisnika o tome. A evo kako to možeš da provjeriš:
http://php.net/manual/en/mysqli.affected-rows.php

Inače ova metoda se zove optimistic locking.