Newsgroup: it.comp.www.php
Titolo: Blocco tabelle

Se nell'interogazione a un database si può soltanto
1) inserire una riga intera
2) cancellare una riga intera
3) richiedere una riga intera
(e quindi non si possono modificare i singoli campi), in questo caso è 
inutile eseguire il lock delle tabelle?
Preciso inoltre che nel caso in esame è più importante la rapidità di 
risposta (anche qualora occasionalmente manchi una riga) rispetto alla 
corretteza dei dati (in pratica....non ci sono soldi in mezzo...ma solo una 
tranquillissima chat). :-)
rob4you
www.outofmind.eu
 

 inutile eseguire il lock delle tabelle?
Dipende. :)
Potresti avere risultati strani nel caso qualcuno stia chiedendo la lista
delle righe mentre altri 10 ne cancellano una.
Teoricamente i meccanismi interni dei DB relazionali garantiscono il
funzionamento tramite l'atomicita` delle operazioni (in pratica se parte
una select, tutte le righe vengono messe in cache, e una eventuale delete
viene eseguita solo alla fine della query, ma le righe che hai preso le
hai in cache finche` tieni la connessione aperta). Un po' come succede
sotto Linux se apri un file con un editor e da un'altra shell lo
cancelli: non lo vedi piu` con ls, ma finche` ce l'hai aperto nell'editor
puoi leggerlo. Appena chiudi l'editor il file sparisce davvero.
Ma dipende sempre dall'implementazione del DB, e` difficile fare un
discorso generale.
Bye.

> Dipende. :)
Nel caso specifico appunto di una semplice chat, con tabella costituita da 
id/id_utente/timestamp/messaggio, in cui, tramite xmlhttprequest, viene 
interrogato il DB da ciascun client ogni secondo per ottenere i nuovi 
messaggi, e invece con un intervallo di tempo più lungo per cancellare i 
messaggi più vecchi di tot, e infine per inserire un messaggio (nuova riga 
nella tabella)......in questo caso sarebbe addirittura "deleterio" usare il 
lock?
rob4you
www.outofmind.eu
 



Credo che il lock non ti serva. In questo caso hai tu il controllo di
quando lanciare il delete. Se metti un limite temporale alle select
(prendi gli ultimi messaggi fino al max a 5 minuti fa) e fai partire la
delete su quelli piu` vecchi (cancella i messaggi piu` vecchi di un mese)
non avrai sovrapposizioni.
Stai attento alla xmlhttprequest. Gia` con solo 10 client avrai 10 request
al secondo (oltre alla normale navigazione sul sito), che sono 10 select
al DB, quindi in totale 20 socket aperte al secondo. Se per caso una
select ci mette un po' di piu` iniziano ad accodarsi e rischi di finire i
socket disponibili.
Prevedi piuttosto un sistema di caching, e magari fai una request ogni 3-5
secondi. L'ideale sarebbe trasformare il client in server, come fa IRC, ma
non so se js supporti qualcosa del genere. In pratica dovresti sfruttare
il keepalive di HTTP/1.1 (configurando anche il server) per far passare
piu` dati sulla stessa connessione.
Bye.

 piu` dati sulla stessa connessione.
In effetti è proprio questo il problema: l'idea delle frequenti richieste al 
server per vedere se c'è qualche messaggio nuovo via xmlhttprequest non è 
che mi piaccia tantissimo. Ma purtroppo mi sa che usando solo js e php/mysql 
non ci sia granché di migliore.
ciaoo, e grazie per le info che mi stai dando.
rob4you
www.outofmind.eu

 passare il termine :-) ) come una chat.
Si`, ma 3 secondi su una chat sono sopportabili. 5 forse meno.
Pero`, ripeto, rischi di trovarti il server carico. Tieni conto anche dei
tempi di connessione. Per aprire un collegamento, tra connect,
handshaking, header ecc. ti parte un secondo abbastanza tranquillamente,
quindi il client probabilmente inizia la seconda request che la prima deve
ancora tornargli.
 
Bisogna, IMO, studiare come mantenere il keepalive e farlo usare ad ajax.
Bye.

 Bisogna, IMO, studiare come mantenere il keepalive e farlo usare ad ajax.
In effetti su google non ho trovato granché...ma mi pare di aver capito che 
il keepalive (nell'HTTP 1.1) č di default, infatti per NON utilizzarlo (con 
ajax) bisognerebbe usare una cosa del tipo: 
oggetto_xmlhttprequest.setRequestHeader("connection", "close"); Quindi i 
tempi del 3-way handshake della connessione tcp non dovrebbero esserci.
rob4you
www.outofmind.eu
 

 tempi del 3-way handshake della connessione tcp non dovrebbero esserci.
Mi dai un'informazione che non avevo. Grazie. :)
Faro` qualche esperimento, visto che ho iniziato a usarlo anche io e me
lo chiedono sempre piu` spesso.
Mi ricordo pero` un'opzione in Apache che lo disattiva. Se puoi, controlla
anche li`.
Bye.

 anche li`.
Si infatti molto contano anche le impostazioni del server. Controllerò. Se 
uno di noi due lo trova per primo..ci rivediamo qui!
:-)
In effetti l'uso di "ajax" è carino, di moda, ma anche semplice. Se usato in 
particolari casi è anche utile (che non è male) ^__^
rob4you
www.outofmind.eu