gestire atomicità durante il caching

[markzzz]

salve, mi servirebbe una illuminazione riguardo la gestione dell'atomicità durante una procedura di caching

lo script realizzato fin ora per determinare se fare il cache o no è questo :

<?
	// controlla se c'è da fare o no il cache, main_check è 0 se è necessario farlo
	$update=mysql_query("UPDATE forum SET main_check='1' WHERE main_check='0'",$mydb);
	// se ha modificato il record (in maniera atomica nel db) il primo utente che arriva crea file di cache, gli altri saltano questo if e lo includeranno semplicemente
	if(mysql_affected_rows()!=0) {
		ob_start();			
        	// creo la pagina che andrà inclusa successivamente
		$query=mysql_query("SELECT c_check, c_id FROM categories",$mydb);
		while ($row = mysql_fetch_array($query, MYSQL_NUM)) {
		?>
			Category <?=$row[1]?>

		<?
		}
		$cachefile="./cache/list.php";
		$fp=fopen($cachefile, 'w'); 
		fwrite($fp, ob_get_contents());
		fclose($fp);
		
		ob_end_clean();									
	}
	
	// includo la pagina (appena creata, oppure se non ha aggiornato nulla quella che già c'era
	include("./cache/list.php");
?>

ed è sulla ultima riga il problema : per il discorso atomicità questo script non funziona.
se per caso uno stà leggendo il file nella cartella cache, ma nel frattempo qualcuno modifica qualcosa e un ulteriore utente si collega alla pagina, rischio di far leggere a uno il file mentre l'altro lo stà scrivendo. stessa cosa se prima uno inizia a scrivere il file e un altro, evitando il primo if, inizia a leggere quel file.

l'unico modo che mi è venuto in mente è utilizzare i semafori, ma da quanto ne sò (forse poco) su php non sono il massimo.

qualcuno ha qualche soluzione magari migliore?

cordiali saluti

[alcio74]

Non so cosa tu intenda di preciso per atomicità, ma da quello che scrivi, a te serve una sorta di gestione delle code di accesso al DB.
Cioè che fino a quando una query non è committata, non esiste nel DB, ma solo in uno dei processi monitor dello stesso.
Sbaglio?
Per fare questo, suppongo che dovresti usare il motore transazionale di MySQL, e quindi InnoDB.
Il che significa poi fare dei lock alle tabelle eccetera.

Leggendo la tua query, però, mi viene da dire che forse l'errore sta nella gestione del tipo di dato.
Se la colonna main_check è di tipo numerico, allora non devi usare gli apici per inserirvi dati.

$update = mysql_query("UPDATE forum SET main_check = 1 WHERE main_check = 0 ",$mydb); 

Non offenderti poi se ti dico, che questo tipo di soluzione di caching mi sembra un po' troppo artigianale: non vai ad controlloare il caching nel browser dell'utente, ma vai a salvare un file in una cartella del server.
Secondo me sbagli la logica del caching stesso, per cui credo di potere dire che butti all'aria le possibilità che ti da' l'accoppiata PHP/DB.

[markzzz]

uhm, mi sà che non hai capito quello che voglio fare io

per quanto riguarda l'ottica del caching, credo di averla intuita. ho letto questa
guida e questa
il server salva le pagine e poi le restituisce così come sono, oppure ne fà una copia e le rimanda. non mi sembra di sbagliare nell'affermare questo

per quanto riguarda il database no, non mi serve una coda di accessi al database. mi serve piuttosto una "coda" di accessi ai file che l'utente stà manipolando/leggendo...

comunque ditemi se sbaglio, potrebbe essere, anche perchè sono alle prime mani

[alcio74]

Originariamente inviato da markzzz
uhm, mi sà che non hai capito quello che voglio fare io

No no, avevo capito benissimo... ed anche leggendo le guide che hai linkato, continuo a non essere d'accordo sul metodo.
A cosa serve salvare una pagina dinamica in un file statico, quando hai un database ed un linguaggio lato server?
Nei link che hai mostrato si parla di lavoro pesante del server nell'interrogazione al DB... quando nello script che presenti c'è comunque il lavoro di salvataggio su disco della pagina nella cartella del server. Peraltro con due query successive che sembrano tutto fuorché ottimizzate!!!!

Sarebbe da fare un benchmark, ma sono convintissimo che se la query è strutturata a dovere e la tabella indicizzata al meglio, usare il DB e generare la pagina da lì sia comunque più veloce.
Tieni conto che poi hai comunque la latenza di trasmissione della pagina creata in cache con il client, quindi non credo che quel tipo di caching possa essere utile come tu credi.

Per quello che riguarda il tuo topic, puoi tranquillamente gestire la visibilità di un articolo con un campo BOOL.
Quando si crea l'articolo, il campo è impostato su FALSE e non è visibile nello spazio pubblico del sito.
Quando chi scrive l'articolo (o chi coordina il sito) decide che l'articolo venga pubblicato, allora ti basta impostare il campo su TRUE.
Se non vuoi fare leggere un articolo già pubblicato, nel caso qualcuno stia modificandone alcuni contenuti, puoi prevedere che nel visualizzazione della FORM di modifica, si imposti di nuovo il campo di visibilità nel DB su FALSE.
Senza di volta in volta generare pagine statiche.

[markzzz]

heheh, si effettivamente per quelle due query non vale la pena fare il cache di una pagina. ma calcola che quella "pagina" creata è solo a titolo di esempio.

in realtà la pagina che devo generare in cache conterrà un numero molto alto di query e di codice php da elaborare... (quindi il carico è abbastanza alto).

sostanzialmente stò creando una specie di blog/forum molto basilare, ma che vorrei comunque fosse cachato

per quanto riguarda il discorso dei TRUE/FALSE, è effettivamente quello che voglio fare, però si rientra in logiche di sincronizzazione/memoria condivisa che andrebbero tenute in considerazione (basti pensare ai problemi di deadlock/starvation che si possono manifestare) ed è per quello che volevo risolverla in altro modo, magari senza l'uso (appunto) dei semafori (usando struttre dati come le condition variables, o i monitor, ma che appunto in php non credo siano implementate).

Originariamente inviato da alcio74
Sarebbe da fare un benchmark, ma sono convintissimo che se la query è strutturata a dovere e la tabella indicizzata al meglio, usare il DB e generare la pagina da lì sia comunque più veloce.

bhè, dipende sempre dal carico lato server. per esempio :
generare la singola pagina (contenente una 20ina di query, codice php per elaborarlo, applicazione fogli di stile su un numero di div che andrà da 50-100 per pagina) una volta sola (in base a se è stato modificata o no) e semplicemente includerla (l'include in php da quanto sò è una operazione poco costosa, in quanto non crea nessun file descriptor e non alloca ulteriore memoria; se per ogni topic ho un file, includerlo non è poi così costoso) sia meno dispendioso che eseguire query/php OGNI vola per OGNI pagina... ma forse quì mi sbaglio...
teoricamente la maggior parte dei forum (credo anche phpBB) dovrebbe fare il cache dei singoli topic, no?

chi più ne sà, più ne scriva

Originariamente inviato da alcio74
Peraltro con due query successive che sembrano tutto fuorché ottimizzate!!!!

perchè dici questo? e dov'è che sbaglierei?

[alcio74]

OK, ti pongo un ultima domanda allora: quand'è che andresti a generare la pagina in cache?
Ti tocca fare una cron o una sorta di click di conferma (e qui poi dovresti anche capire come e chi dovrebbe fare questo click), perché se fai generare la pagina ad ogni accesso utente, stai fresco se il sito ha un certo carico!

[markzzz]

l'idea è questa. supponi che quella sia la pagina delle "news" di un sito...e voglio che si crei quando un qualsiasi utente modifica tale news. se la modifica andrà a modificare il valore della var main_check, mettendola a 0.

appena succederà questo, e un utente entrerà, modificherà effettivamente 0 in 1, entrerà nello script che genera la pagina, la genererà rimpiazzando quella vecchia in cache, e da quel momento in poi ogni utente che vorrà visualizzare quella pagina (trovando main_check già a 1) la prenderà semplicemente della cache.

dici che questo non ottimizzi il tutto? nel senso, supponiamo che quella pagina abbia una 20ina di query, è meno dispendioso includere quella pagina che non generarla per ogni utente che si collega...dico male?

spero di essere stato un pò più chiaro... :master:

[alcio74]

Si ho capito.... ma non mi convince.
Forse sono io un po' tarato, ma credo che sia un orpello inutile.
Quanti utenti poi, potrebbero andare a scrivere questa pagina di fantomatiche news?
Metti che ci siano tre collaboratori e che tutti e tre inseriscano una notizia nel giro di pochi minuti.
Chi ha la precedenza su chi per andare a salvare il file?
Quante volte rischi di salvare il file per unità di tempo???
A quel punto, secondo me, ti conviene andare a salvare i dati in un DB, generare uno script che legga il DB ad intervalli regolari e che (se necessario) salvi i risultati in un file XML, che poi leggerai nella tua homepage come se fosse un feed RSS.

Mi spiego???

[markzzz]

ma, effettivamente non son degli utenti che possono o no generare le pagine, chiunque arrivi per primo e vede che la pagina delle news è da aggiornare, la aggiorna in modo che i successivi include siano relativi alla pagina aggiornata...

per quello mi serviva un meccanismo di sincronizzazione sui files
come dici te forse si è un "orpello inutile", ma credo sia più veloce includere la singola pagina e generarla quando sia effettivamente da aggiornare, piuttosto che "generare" la pagina ogni volta che un utente si collega.. no? non capisco cosa non ti convince in tutto questo, è sicuramente meno dispendioso secondo me

per esempio, questo singolo topic di forum html (e in generale tutto il sito?!?!) viene generato ogni volta che un utente lo visualizza oppure è in cache e viene servito?

[alcio74]

Manco a dirlo: viene generato all'accesso dopo interrogazione al DB.