read/write sicuro su file senza flock()

[skidx]

Salve, sto progettando un sistema di caching su file di dati provenienti dal DB.
Appurato il fatto che su flock() non si può fare affidamento perché fallisce in una moltitudine di situazioni (situazioni anche abbastanza comuni), rimane il problema della lettura / scrittura concorrente su file, in maniera sicura.

Io ho pensato questo metodo, vorrei sapere che ne pensate.
- In scrittura, viene usato un record sul database per ottenere un accesso esclusivo. Il metodo è funzionante e sicuro ovunque a prescindere da OS e configurazione. Il degrado di prestazioni è minimo perché la riscrittura del file di cache è necessaria solo quando devo comunque rileggere i dati nuovi dal DB, quindi già avevo una connessione obbligata.

- La scrittura avviene su un file temporaneo diverso da quello di cache, a scrittura avvenuta viene fatto l'unlink() del file originale e poi il rename().

- Come ulteriore verifica di integrità (nel caso lo script di scrittura venisse interrotto per qualsivoglia motivo), potrei scrivere dentro al file, all'inizio, il numero di byte del pacchetto di dati che ci andrò a scrivere (o una crc32 se proprio uno vuol essere caccoloso), da verificare poi in lettura.


Opinioni o tecniche alternative (purché rispondano agli stessi requisiti)?

Grazie.

[piero.mac]

retrocedendo....

per l'integrita' del file userei MD5_file()

lascerei sempre un file di backup (un n-1) da gestire come alternativa.

no comment per il primo punto....

[skidx]

Ciao Piero, grazie per la risposta.

Originariamente inviato da piero.mac
per l'integrita' del file userei MD5_file()
lascerei sempre un file di backup (un n-1) da gestire come alternativa.

Sicuramente è una funzione efficace, ma a me per il tipo di utilizzo (una cache appunto) serve qualcosa di molto veloce. se i byte letti non corrispondono in numero a quelli dichiarati cancello il file e vado di DB, non c'è nessun problema.
La scrittura avviene SICURAMENTE in mutua esclusione, quindi la corruzione del file (numero di byte esatto ma qualche byte non corretto) è probabile tanto quanto la scrittura di un qualsiasi file nel sistema, quindi estremamente rara.

no comment per il primo punto....

No comment nel senso che ti sembra ok o che ti sembra che abbia detto una cagata?

[piero.mac]

Originariamente inviato da skidx
No comment nel senso che ti sembra ok o che ti sembra che abbia detto una cagata?

nel senso che l'idea e' buona .... bisognera' valutare la realizzazione e la performance rispetto ad una equivalente "cache" salvata in una tabella....

[skidx]

Originariamente inviato da piero.mac
nel senso che l'idea e' buona .... bisognera' valutare la realizzazione e la performance rispetto ad una equivalente "cache" salvata in una tabella....

in pratica mi appoggio al db solo per ottenere la mutua esclusione sulla scrittura del file.

Una cosa tipo
SELECT @value = timestamp FROM semaphore WHERE id = 3;
UPDATE semaphore SET timestamp = NOW() WHERE id = 3 AND timestamp = @value;

sull'update controllo l'affected_row, essendo l'update di un record mutuamente esclusivo per definizione solo uno degli ipotetici N client connessi in simultanea avrà affected_row = 1, e sarà quello che procederà a scrivere sul file.
Al posto del timestamp forse basta anche un intero da incrementare.

Sul discorso cache salvata direttamente nel DB piuttosto che su disco, mi sa che dipende molto dalle risorse e dai settaggi del server caso per caso. In quelli condivisi spesso il collo di bottiglia è proprio sulle connessioni simultanee al DB, e la cache su file in questo senso ne aumenterebbe scalabilità e prestazioni.

Certo tenendo la cache su DB risolvo a priori qualsiasi problema di corruzione dei dati e mutua esclusione, ma avrei per qualsiasi richiesta l'overhead di connessione e query al database, cosa che invece non ho facendo un readfile() o un eventuale include.

[piero.mac]

ma tu intendi un file di dati tipo csv oppure un file template popolato dalla cache, cioe' un file html pronto da spedire al browser?

[skidx]

Originariamente inviato da piero.mac
ma tu intendi un file di dati tipo csv oppure un file template popolato dalla cache, cioe' un file html pronto da spedire al browser?

pensavo a entrambi gli usi, a seconda dello scopo.
Per pagine che cambiano raramente cachare il file html già pronto per l'invio (risparmiando quindi un mucchio di tempo per tutte le richieste successive), in altri casi dove è richiesto un maggiore dinamismo pensavo di cachare i risultati di query più o meno complesse serializzando su file l'array con i risultati.


Ho pensato anche a un meccanismo per evitare che la creazione della cache sia poi più pesante del vantaggio che se ne trae. Il file della cache viene ricostruito solo se è passato un certo intervallo di tempo dall'ultima volta.
Per fare un esempio che capiamo tutti, su un thread recente del forum OT dove la gente risponde ogni 10 secondi, se mi metto a fare query + cache in continuo ho un rallentamento peggiore che lasciando tutto puramente dinamico. Se invece il thread è vecchio e non ci sono più interventi frequenti posso cacharlo su file e chi ci accederà in lettura non avrà bisogno di accedere al DB.

[piero.mac]

credo che questa tua idea sia nata a seguito di un thread dei giorni scorsi..... parlando di campi calcolati. Comunque tutto dipende dalla frequenza e dall'importanza degli aggiornamenti, ne convengo.

per esempio ho un gestionale in intranet dove essenzialmente si hanno tre tipi di interrogazioni dipendenti dal privilegio dello user. Bene, poiche' si tratta di raccogliere e calcolare un certo numero di dati (ovviamente non tutti) da una ventina di tabelle ed essendo queste interrogazioni "basiche" cioe' obbligatorie per accedere poi alla selezione di dati successivi, ho generato tre file html da inviare direttamente al browser con la data/ora dell'aggiornamento del file.

Se l'utente non trova le ultime identita' inserite allora invia la richiesta del delta mancante dall'aggiornamento al momento corrente che verra' effettuato su db. Di solito questi dati sono visibili ma non ancora disponibili perche' il processo di lavoro e' ancora in corso.

Questo a grandissime linee. Si potrebbe anche usare la sintassi heredoc.... ma deve passare dal parser.

Ovviamente mi riferisco ad una "lista" di record da cui, effettuata una scelta, si tornera' alla gestione diretta su db. Ma e' comoda perche' il 50% delle connessioni si limita a consultare questi dati come una volta si faceva con i tabulati cartacei.

[skidx]

Originariamente inviato da piero.mac
credo che questa tua idea sia nata a seguito di un thread dei giorni scorsi..... parlando di campi calcolati.

no, è parte di un sistema su cui sto lavorando (con millemila interruzioni) da diversi mesi

Comunque grazie 1000 delle opinioni, se non altro non mi hai fatto sentire solo (faccio sempre thread di gran successo )