On Mon, 12 Dec 2011 18:49:38 +0100, Alessandro Dentella wrote:
On Fri, Dec 02, 2011 at 03:37:34PM +0000, Daniele Varrazzo wrote:
Ah, cherrypy è multithread, ma lo storage su file delle sessioni non
è thread safe, me lo sono dovuto scrivere io. Mi chiedevo come mai
l'autore originale del programma usasse memcached solo per salvare
(si fa per dire le sessioni). Quando abbiamo fatto il multi-nodo, un
mio collega ha visto lo storage delle sessioni su database (che
potrebbe servirci se volessimo scalare su diverse macchine) e ha
detto che anche quello è finto.
Nel cammino verso l'indipendenza dell'applicativo dal processo voglio
portare le sessioni su database.
Uhm... ok... su file non vanno più bene? Assumo che lo vogliate fare
per scalare oltre la singola macchina, altrimenti non c'è ragione.
Considerando che attualmente le singole request vengono evase in 100
ms
circa, pensavo di farlo utilizzando SELECT FOR UPDATE, così da
garantirmi
che nessun'altra request possa leggere finché non ho evaso la
request.
E perché vorresti impedire di leggere? Uno fa tanto per progettare un
database che consenta letture e scritture concorrenti e tu infili gli un
ombrello nella ruota davanti? :)
Ci sono idee migliori o controindicazioni? (a parte che tengo
occupata una
connessione solo per questa transazione)
Controindicazioni dei lock espliciti? Quante ne vuoi. Non è una buona
idea. Sono pochi i problemi che hanno davvero bisogno di un lock per
essere risolti, e tu non sei neanche sicuro di avere un problema: ti
direi lascia perdere che rischi di fare più danni di quelli di cui hai
bisogno.
Guadando il codice di django non ci leggo precauzioni contro questa
eventualità, mi sfuggono o cherry-py non è solo?
Forse semplicemente non è un problema. Se hai un burst di letture sullo
stesso utente dovuto a richieste asincrone, dovrebbero leggere tutte uno
stato consistente della sessione. I problemi di cherrypy sono
ridicolamente altri, secondo me django due o tre persone l'hanno testato
e va bene così com'è. Con cherrypy a volte le sessioni leggevano un file
e lo trovavano vuoto perché la richiesta di prima l'aveva aperto per
scrivere (con open(name, 'w')) e non l'aveva ancora chiuso; con postgres
questo problema non esiste: o il vecchio, o il nuovo, ma un record
consistente ce lo trovi. Le sessioni su postgres di cherrypy erano finte
perché mancavano dei metodi che servivano, proprio pezzi non scritti e
oggetti mai usati, non avevano problemi di concorrenza. Di esistenza,
casomai.
A proposito, poi com'è andata con la storia di tornado e psycopg?
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
