Azuriranje cesto posecenog fajla

[ zgas @ 12.10.2009. 12:47 ] @

Na hostingu mi postoji fajl koji se azurira svake sekunde.
(upitanju su neke finanskiske transakcije berzanskog tipa, neophodno je tako)
Tome fajlu isto tako pristupa oko stotinak korisnika i to ajaksom takodje svake sekunde.
(oni moraju na ekranu da imaju trenutno stanje tih berzanskih transakcija)
Nadam se da razumete, sistem ne moze da se menja - mora biti takav.

Posto sajt jos nije u toliko posecen, ne mogu da znam da li dolazi do gresaka prilikom azuriranja i iscitavanja sadrzaja.

Fajl se azurira i pritome se na njega stavlja eksluzivni lock da ga niko ne moze citati dok se ne zavrsi azuriranje.

Problem je sledeci:
Sta ako u sred iscitivanja fajla od nekog korisnika bude izvrseno azuriranje? Korisnik ce dobiti netacne podatke?

Resenje je pretpostavljam da se uradi lock, kada korisnik cita podatke da se podaci ne mogu azurirati.

To nisam smeo da uradim iz sledeceg razloga:
Fajl mora da se azurira svake sekunde, a ako bude bilo puno korisnika koji citaju fajl
to azuriranje nece biti moguce zbog stalnog zkljucavanja fajla od strane korisnika. Azuriranje ce kasniti.

Da li imate savet ili resenje kako da azuriranje ne kasni, a korisnici da iscitavaju fajl bez greske?

[ b0ris @ 12.10.2009. 12:50 ] @

Ako ti se fajl azurira svake sekunde, to bi onda znacilo da i korisnici moraju svake sekunde da rade refresh.
To jest nikad nebi bili sigurni da li su podaci tacni?

[ b0ris @ 12.10.2009. 12:53 ] @

Sto se tice problema azuriranje usred ispisa, to bi mogao da sredis recimo nekim tokenom.
Dok korisnik iscitava fajl ti ujedno pozivas korisnika i proveravas token, u koliko se token promeni ti mu opet refreshujes stranu.
Ovo je naravno stres za server jer radis vise konekcija napred nazad po jednom korisniku.
Znaci on dodje dobije token "asd" krene iscitavanje, tokom iscitavanja ti zoves njega i proveris njegov token, u koliko je token los (not equal "asd") ti opalis refresh.

Eto to je najruznije moguce resenje. Potrudicu se da smislim nesto bolje.

Update:
Mozes i naravno da radis to samo sa strane korisnika, da korisnik poziva taj fajl sa tokenom, kad se iscita na kraju ponovo posaljes token i proveris u koliko se razlikuju refreshujes.
To je znatno bolje :)
Znaci
dobije token na pocetku izvrsavanja i na kraju, ako su isti sve ok ako nisu refresh.

[ djoka_l @ 12.10.2009. 12:53 ] @

Pre svega, korisnici ne traba da zaključavaju fajl zbog čitanja. Proces koji piše treba da zaključava. Ovo se, kada je reč o bazi podataka, radi tako što postoji slika podataka koja je ažurana sa poslednjim COMMITom i "prljavi blok" u koji neko upisuje podatke. Kada se Transakcija ažuriranja završi, prljavi blok se upisuje u bazu i on postaje nova, ažurna slika stanja.

Kako ti radiš sa fajlovima, moguće rešenje je da postoje dva fajla: jedan koji se čita i njegova kopija koja se ažurira. Kada se završi ažuriranje, ažurirani fajl se iskopira za čitanje...

[ zgas @ 12.10.2009. 17:43 ] @

Hvala svima i samo da ispravim "b0ris" korisnika:
Kada je tema otvorena napisano je da korisnici ajaksom svake sekunde iscitavaju fajl.
Znaci nema potrebe za nekim drugim refreshom, to vec cini ajaks svake sekunde.

"djoka_l" hvala na komentaru, sada mi je jasnije kako je to reseno u DB. Sto se tice ovog resenje za fajl da li bi moglo malo da pojasnimo.
Znaci kod fajlova bi to islo ovim putem:

1. kreiranje privremenog fajla
2. brisanje radnog fajla
3. kopiranje privremenog u radni fajl

Znaci drugi i treci korak bi izgledali ovako:

Code:
ulink("radni_fajl.php");
copy("privremeni_fajl.php", "radni_fajl.php"))

Moje pitanje je, koliko je to brze od ovog procesa koji se odvija na serveru:

1. Kreiram string $sadrzaj koji treba upisati u fajl
2. tada cinim ovu proceduru:

Code:
if (!$handle = fopen($filename, 'w')) throw new Exception("Cannot open file ($filename)");

if (flock($handle, LOCK_EX)) {

    if (fwrite($handle, $somecontent) === FALSE) throw new Exception("Cannot write to file ($filename)");

    flock($handle, LOCK_UN);

} else {
    throw new Exception("Couldn't lock the file !");
}

fclose($handle);

-------------------------------------------

Stvarno resenje sa kopiranjem meni izgleda brze mada ne znam koliko je to u milisekundama (sadrzaj fajla je inace oko 1 - 10 KB).
Medjutim ni to resenje mislim ne zasticuje korisnika od citanja pogresnih podataka,
jer sta ako korisnik iscitava podatak u medjuvremenu dok je fajl izbrisan a jos nije kopiran privremeni fajl u radni fajl?

Mozda je jos bolje resenje da se umesto kopiranja izvrsi RENAME privremenog fajla u RADNI?
Ali i tu se moze desiti da korisnik iscitava fajl u medjuvremenu izmeju brisanja starog radnog fajla i
RENAME privremenog fajla u novi radni fajl.

Sugestije?

[ zgas @ 12.10.2009. 18:07 ] @

Cini mi se da sam nasao resenje u PHP dopkumentaciji zaa RENAME:

Code:
Note, that on Unix, a rename is a beautiful way of getting atomic updates to files.

Just copy the old contents (if necessary), and write the new contents into a new file, then rename over the original file.

Any processes reading from the file will continue to do so, any processes trying to open the file while you're writing to it will get the old file
(because you'll be writing to a temp file), and there is no "intermediate" time between there being a file, and there not being a file
(or there being half a file).

Oh, and this only works if you have the temp file and the destination file on the same filesystem (eg. partition/hard-disk).

Moze komentar posto mi nije bas najasnije o cemu se ovde govori.

[ Milos911 @ 12.10.2009. 18:33 ] @

Kopiras test fajl, das mu ime temp, odradis to sto treba, uradis "rinejm" u test fajl. Posto se stari fajl onda ne zakljucava, nikako ne mozes da zeznes korisnike :)

[ zgas @ 12.10.2009. 19:56 ] @

Problem je sto RENAME ne moze bas da bude "atomic".

Ukoliko fajl_za_korisnike vec postoji, prvo moram da ga izbrisem sa unlink(), pa tek onda da izvrsim rename(temp_file, file_za_korisnike);

Ako izvrsim promenu imena bez predhodnog brisanja vec postojeceg fajla, PHP mi daje upozorenje da fajl za korisnike vec postoji i vraca false.
Znaci moram predhodno izbrisati fajl.

Znaci tu postoji jas izmedju brisanja fajla i rename. Cini mi se da u PHP 5.2.9 i 5.3 ne mora da se radi brisanje, tako da u tim verzijama RENAME jeste atomic. Ali to treba proveriti za te verzije jer nisam siguran u to.

[ Milos911 @ 12.10.2009. 22:28 ] @

Citat:

For those who are still confused about the behavior of rename() in Linux and Windows (Windows XP) when target destination exists:
I have tested rename($oldName, $targetName) in PHP 5.3.0 and PHP 5.2.9 on both OS and find that if a file named $targetName does exist before, it will be overwritten with the content of $oldName

http://us.php.net/manual/en/function.rename.php
:)

[ zgas @ 13.10.2009. 10:48 ] @

Ljudi imam na serveru 5.2.9 verziju i rename ne moze da se izvrsi (i ne desava se update) na fajlu koji vec postoji, php generise upozorenje a rename vraca false.

Znaci ovo iz PHP dokumentacije nije tacno.

_{[Ovu poruku je menjao zgas dana 13.10.2009. u 11:59 GMT+1]}

[ b0ris @ 13.10.2009. 13:47 ] @

Pogledaj dozvole koje su ti na fajlu.
Tesko da dokumentacija nije tacna ;)

[ zgas @ 13.10.2009. 17:00 ] @

Puno hvala "b0ris", u pitanju su bele dozvole na fajlu.

Sada imam trenutan update fajla (php verzija 5.2.9):

1. kreiram privremen fajl
2. rename privremen fajl u radni fajl

I to je to, korisnici ne mogu procitati fajl u toku njegovog kreiranja, i kreiranje fajla ne moze biti dok ga korisnik cita.
Ako sam ovo sve dobro razumeo?

I jedno pitanje: Da li se je ovo kljuc za kreiranje kvalitetnog KEŠ sistema?

Puno hvala svima.